Method for safely starting and playing content of peripheral storage device
By working together with the Android system, the MCU security chip uses the identification file generated by the CRC algorithm to double encrypt the external storage device, solving the problem of the Android system's inadequate security detection of external storage devices and achieving secure startup and playback.
Patent Information
- Application Number
- CN202510595180.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-09
- Publication Date
- 2025-09-12
AI Technical Summary
The existing Android system does not fully detect the security of external storage devices, which may cause system crashes or poisoning, resulting in low security.
The MCU security chip is used to encrypt and verify peripheral storage devices, and works in conjunction with the Android system through I2C communication to ensure that only devices encrypted by the supporting program can start and play content normally. The CRC algorithm is used to generate identification files A and B for double encryption of devices and content to ensure security.
It achieves secure startup of peripheral storage devices and secure playback of content, improves system security, and prevents unauthorized device access and content leakage.
Smart Images
Figure CN120632902A_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the technical field of LCD display and playback, and in particular relates to a method for safely starting and playing the contents of an external storage device. Background Art
[0002] The LCD commercial display industry is facing increasing demands for display and content security. This is especially true in government and enterprise organizations, where the legality and compliance of content being displayed are of paramount importance, placing high demands on security. Existing Android systems lack adequate security checks for storage devices, leading to system crashes or malware attacks when external storage devices are connected, resulting in low security. Summary of the Invention
[0003] The purpose of the present invention is to provide a method for securely starting and playing the contents of an external storage device, aiming to solve the problem that the existing technology is unable to fully detect the security of the external storage device.
[0004] The present invention is implemented as follows: a method for securely starting and playing the contents of an external storage device, the method comprising the following steps:
[0005] Step S1: Power is supplied to the Android board system, and the MCU security chip is powered and starts running. The MCU security chip receives the encrypted instruction sent by the Android system requesting normal startup. The MCU security chip verifies the instruction. If the verification passes, the MCU security chip replies with the instruction to notify the Android system to start normally. If the verification fails, the Android system cannot start normally and actively initiates a power-off request instruction to the MCU security chip.
[0006] Step S2: Connect the encrypted external storage device to the interface of the Android board. The MCU security chip will communicate with the external storage device. If the MCU security chip recognizes that the connected external storage device has been encrypted by the corresponding program and successfully decrypted using the corresponding algorithm, it will actively initiate the operation of starting the Android system. If the recognized external storage device is not encrypted or the decryption fails, the Android system cannot be started;
[0007] Step S3: When the Android system is powered on and receives the startup command from the MCU security chip, it boots up normally and enters the system. After entering the system, the communication path of the external storage device is switched to the Android system. The Android system actively reads the content in the external storage device and determines whether the content has been encrypted by the supporting program. If it has been encrypted, it is decrypted using the supporting encryption and decryption algorithm. If the decryption is successful, the decrypted file is played. If the content is not encrypted or the decryption fails, the playback operation is not performed.
[0008] A further technical solution of the present invention is: it also includes step S4: unplugging the external storage device, the Android system will passively receive the uninstall broadcast of the external storage device, the Android system will send an instruction to the MCU security chip, informing it that the external storage device has been uninstalled and needs to be shut down, and the MCU security chip starts a signal to power off the Android system to complete the shutdown operation of the Android system.
[0009] A further technical solution of the present invention is: in step S1, the startup of the Android system is determined by the MCU security chip, the MCU security chip pulls up the power supply gpio control pin of the Android system, and the powered Android system starts to start and run. During the operation, it communicates with the MCU security chip through the I2C signal and sends an encryption instruction requesting normal startup. After receiving the data sent by the Android system side, the MCU security chip processes it. If the startup of the Android system is actively triggered by the MCU security chip, the MCU security chip replies to the data on the Android system side as an instruction to allow startup. If the startup of the Android system is not actively triggered by the MCU security chip, the MCU security chip replies to the data on the Android system side as an instruction not to allow startup.
[0010] A further technical solution of the present invention is: the Android system processes the data replied by the MCU security chip after receiving it. If the MCU security chip receives an instruction to allow startup, the system enters normally; if the MCU security chip receives an instruction not to allow startup, the Android system actively sends an instruction to the MCU security chip again to request a shutdown instruction. After receiving the shutdown request instruction, the MCU security chip actively pulls down the gpio control pin to power off the Android system.
[0011] A further technical solution of the present invention is: before the external storage device with content is connected to the Android board, it must first be connected to the PC end, the encryption algorithm on the PC end reads the important characteristic information of the storage device, and generates data through the CRC algorithm and writes it to generate an identification file A, sets a password for the content in the external storage device, generates data through the CRC algorithm and writes it into a file to generate an identification file B.
[0012] A further technical solution of the present invention is: after the external storage device is connected to the Android board, the MCU security chip first queries and parses the identification file A when reading the external storage device, and compares and verifies the data therein. If the verification is successful, it means that this device is a compliant storage device. After the verification is successful, the MCU security chip actively starts the Android system. After the Android system is started, the content of the external storage device is read, the content in the storage device is searched, and the identification file B is identified. If all the queries exist, the identification file B is parsed, and the file names of all files and the corresponding file MD5 values are extracted. After obtaining these data, the MD5 values are compared with each original file. If the comparison verification passes, it means that the content is decrypted.
[0013] A further technical solution of the present invention is: if it is found that there is only a compressed package in the external storage device, it will be determined whether a password needs to be filled in during decompression. If no prompt is given to fill in a password, it means that the package has not been encrypted by the supporting program and no processing is performed; if it is determined that a password needs to be filled in, a password verification is performed. After the verification passes, the decompression operation is performed. After the decompression is completed, the file names of all the contents and the md5 values of the corresponding files are collected.
[0014] A further technical solution of the present invention is: when the external storage device is a USB flash drive, communication is performed through the USB protocol. When the MCU security chip has not yet started the Android system, the default path of the USB Switch chip is the connection between the USB peripheral interface and the MCU security chip. When the Android system is powered on and receives the startup instruction of the MCU security chip, it will boot up normally and enter the system. After entering the system, the Android system will pull up the gpio control pin of the USB Switch chip, switch the communication path to the Android side, communicate with the Android system, and the Android system will actively read the contents of the USB flash drive.
[0015] A further technical solution of the present invention is: when the external storage device is a TF / SD card, communication is performed through the SDIO protocol. When the MCU security chip has not yet started the Android system, the default path of the SDIO Switch chip is to connect the TF / SD peripheral interface to the MCU security chip. When the Android system is powered on and receives the startup instruction of the MCU security chip, it will boot up normally and enter the system. After entering the system, the Android system will pull up the gpio control pin of the SDIO Switch chip, switch the communication path to the Android side, communicate with the Android system, and the Android system will actively read the contents of the TF / SD card.
[0016] The beneficial effect of the present invention is that by building two independent encryption algorithms into the storage device, the external storage device itself is encrypted and the data within the device is encrypted separately. Decryption is performed using only the corresponding encryption and decryption algorithms. This one-to-one correspondence and independent two-layer encryption and decryption ensures the security of the storage device. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 It is a specific flow chart of the present invention. DETAILED DESCRIPTION
[0018] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments.
[0019] The present invention provides a method for securely booting and playing the contents of a peripheral storage device, utilizing two-in-one encryption systems of an MCU security chip system and an Android system to achieve the control requirements of securely booting and securely playing the contents of a peripheral device. The following structures are involved in realizing the control of secure booting of an Android motherboard and implementing secure playback.
[0020] Android board, supports U disk or TF (SD) card communication;
[0021] Equipped with an MCU security chip, its first function is to determine whether the inserted USB flash drive or TF (SD) card has been encrypted by the supporting program. If it has been encrypted, it will decrypt it; otherwise, no action will be taken. Its second function is to control the high and low levels of the startup signal of the GPIO control pin to power on and off the Android system and to provide feedback on the request command (I2C communication) issued by the Android system to determine whether it can perform a secure boot. The process here has a prerequisite: the first function of the MCU security chip has been started and the encrypted storage device has been successfully decrypted before entering the second function, which is the next step;
[0022] The USB switch chip and the SDIO switch chip are designed to switch communication between external storage devices and the Android system and the MCU security chip. The communication paths of the two switch chips are determined by the levels of the GPIO control pins on each chip. (The Android system controls the high and low levels of the GPIO control pins to switch the switch chip paths. When the Android system is not started, the default level determines the path, that is, communication with the MCU chip, which depends on the hardware design.) The GPIO switching level is set to low by default (depending on the hardware design) for communication with the MCU security chip. When Android boots normally and enters the system, it pulls the GPIO switching level high, switching the paths of the two switches to the Android end, communicating with the Android system.
[0023] The safe boot and safe playback process is as follows:
[0024] The Android board system receives power, and the MCU security chip receives power and starts running. The Android system boots up based on the MCU security chip. For the Android system to power up and run normally, the MCU security chip must first pull up the Android system's power GPIO control pin. Once powered, the Android system starts booting and running. During this process, it communicates with the MCU security chip via I2C signals and sends a request for a normal boot. The MCU security chip decrypts the Android system's request for a normal boot. If verification is successful, it responds with a command to notify the Android system to boot normally. If the Android system's request for a normal boot fails verification, the Android system will not receive the correct boot command and will not boot normally. It will then initiate a power-off request to the MCU. Upon receiving the request, the MCU security chip pulls down the Android system's GPIO control pin's power control signal, powering off the Android system.
[0025] The Android system boot is initiated by the MCU security chip, which powers on the Android system by pulling a GPIO high. During power-up, the Android system sends a "request for encrypted boot" command (for example, the byte data stream 0xaa 0x02 0x07 0x01 0x03 0x00 0xb7). After receiving the data (request for encrypted boot: 0xaa 0x02 0x07 0x01 0x03 0x00 0xb7), the MCU security chip processes it. If the Android system boot is initiated by the MCU security chip, the MCU security chip responds with the following message (allowing the boot): 0xaa 0x82 0x07 0x01 0x01 0x01 0x35. If the Android system boot is not initiated by the MCU security chip (due to other factors), the MCU security chip responds with the following message (not allowing the boot): 0xaa 0x82 0x07 0x01 0x00 0x01 0x34. The Android system processes the byte stream data differently based on the response from the MCU security chip. If it receives a boot-allowing command (e.g., 0xaa 0x82 0x07 0x01 0x01 0x01 0x35), it enters the system normally. If it receives a boot-disallowing command (e.g., 0xaa 0x82 0x07 0x01 0x00 0x01 0x34), it proactively sends a shutdown request to the MCU security chip: 0xaa 0x02 0x06 0x01 0x01 0x00 0xb4. The MCU security chip processes the data (shutdown request) sent by the Android system: 0xaa 0x02 0x06 0x01 0x01 0x00 0xb4. Upon receiving this command, the MCU security chip proactively pulls down the GPIO pins to power off the Android system.
[0026] The conditions that determine whether the Android system can boot normally are triggered by the external storage device. This external storage device can be a USB flash drive or a TF (SD) card. These devices can be encrypted in two steps on the Windows system using the Windows encryption algorithm program. The first step is to encrypt the contents of the storage device (videos, images, etc.); the second step is to encrypt the storage device itself. The Windows encryption algorithm exe installer is installed on the PC. Insert the USB flash drive or TF (SD) card with the contents (videos, images, etc.) into the computer, then open our program and select the corresponding storage device. The first step is to read some important characteristics of the storage device, generate data using the CRC algorithm, and write it to generate an identification file A. When the MCU reads the USB flash drive, it first queries and parses the identification file A, comparing and verifying the data within it. A successful verification indicates that the device is a compliant storage device. The CRC algorithm uses the existing CRC32 algorithm. CRC32 (Cyclic Redundancy Check 32-bit) is a commonly used hash algorithm primarily used to detect errors in data transmission or storage. It generates a 32-bit checksum by performing specific mathematical operations on the data to verify data integrity. The comparison check compares the hash algorithm data stored in File A. This data is generated by performing specific mathematical operations on certain characteristic data using the CRC32 algorithm to generate a 32-bit checksum. The MCU chip is pre-programmed with the characteristic information required for the CRC32 algorithm to perform data comparison and verification.
[0027] The second step is to encrypt the contents of the storage device, such as compressing the videos, pictures and other files, setting the password for the compressed package, and then the Android system will perform password verification. The correct password must be entered to decompress the package. After the decompression is completed on the Android side, the compressed package is deleted, and all the video or picture file names and the corresponding MD5 values are collected, and written into the file through the CRC algorithm to generate the identification file B.
[0028] When an encrypted storage device, such as a USB flash drive or TF (SD) card, is connected to the Android's USB or TF (SD) interface, the MCU security chip communicates with it. If it's a USB flash drive, communication is carried out using the USB protocol, while a TF (SD) card communicates using the SDIO protocol. Furthermore, when the MCU security chip hasn't yet started the Android system, the USB Switch chip defaults to connecting the USB peripheral interface to the MCU security chip. This allows the MCU security chip to communicate with the external USB flash drive. The same principle applies to TF (SD) cards. The SDIO Switch chip defaults to connecting the TF (SD) peripheral interface to the MCU security chip. When the MCU security chip recognizes that the connected external storage device has been encrypted by the corresponding program and then successfully decrypted using the corresponding algorithm, indicating that the external device is a compliant storage device, it will proactively initiate the Android system boot operation. If the recognized external storage device is not encrypted or decryption fails, the MCU security chip will not take any further action, resulting in the Android system being unable to boot.
[0029] When Android is powered on and receives the startup command from the MCU security chip, it will boot up normally and enter the system. After entering the system, Android will pull up the gpio control pins of the USB Switch and SDIO Switch, switch their communication channels to the Android side, and communicate with the Android system. The Android system will actively read the contents of the USB flash drive or TF (SD) card to determine whether the content has been encrypted by the supporting program. If it has been encrypted, it will be decrypted using the supporting encryption and decryption algorithm. If the decryption is successful, the decrypted file (video, picture, etc.) will be played. If the content is not encrypted or the decryption fails, there will be a corresponding prompt and the playback operation will not be performed.
[0030] After the Android system starts, it will read the contents of the USB flash drive or TF (SD) card. It will first search for video or image files and identification file B. If both are found, it will parse the identification file B. First, a 32-bit checksum is stored in the identification file B. This data is generated by performing a specific mathematical operation on some feature data using the CRC32 algorithm. Like the identification file A, it is generated by the same set of algorithms. The difference between the identification files A and B is that the feature information introduced into the algorithm is different, and the generated data results will be different. Extract the file names and corresponding MD5 values of all files. After obtaining these data, compare them with the MD5 values of each original file (video or picture). If the comparison verification passes, it means that the content has been decrypted. If the query finds that there is only a compressed package in the storage device, it will determine whether a password is required when decompressing. If there is no prompt to fill in a password, it means that this package has not been encrypted by the supporting program and naturally no processing is performed. If it is determined that a password is required, a password verification is performed. After the verification passes, the decompression operation is performed. After the decompression is completed, the compressed package is deleted. All video or picture file names and the corresponding file MD5 values are collected and written to the file through the CRC algorithm to generate the identification file B. Running the Windows-side encryption algorithm exe installation program will compress the videos, pictures and other files in the storage device and set the compressed package password. In the Android system, the corresponding decompression password can be preset in advance. When the program flow reaches the password verification, it will use the pre-set password for verification.
[0031] Finally, when the USB flash drive or TF (SD) card on the peripheral device is unplugged, the Android system will passively receive the uninstall broadcast of the peripheral storage device. At this time, the Android system will send a command to the MCU security chip through I2C, informing it that the peripheral device has been uninstalled and needs to be shut down. The MCU security chip will start the signal by pulling down the gpio control pin to power off the Android system, completing the shutdown operation of the Android system.
[0032] The key point of this technical solution is that the Windows-based encryption program has two independent encryption algorithms built in. When the program is running, it uses these two independent encryption algorithms to encrypt the external storage device (USB flash drive or TF (SD) card) and the content data (videos, images, etc.) on the device. Decryption is also performed by the corresponding encryption and decryption algorithms. The two independent encryption and decryption layers ensure higher security.
[0033] When a peripheral storage device is connected to the Android board, the MCU security chip actively initiates communication with it (the corresponding communication methods for the peripheral storage device are USB and SDIO, such as a USB flash drive or TF (SD) card), and then performs decryption. After the Android system securely boots, it actively switches the communication paths of the USB Switch chip and the SDIO Switch chip by pulling up the corresponding chip path switching pin (GPIO signal). This switches the path from the MCU security chip to the Android system, allowing the Android system to read the peripheral storage (USB flash drive or TF (SD) card) normally. It then performs decryption. Only after the MCU security chip has successfully decrypted the peripheral storage can the Android system boot normally. This security process ensures the implementation of a secure boot and secure playback solution.
[0034] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.
Claims
1. A method for securely starting and playing the contents of an external storage device, characterized in that: The method comprises the following steps: Step S1: Power is supplied to the Android board system, and the MCU security chip is powered and starts running. The MCU security chip receives the encrypted instruction sent by the Android system requesting normal startup. The MCU security chip verifies the instruction. If the verification passes, the MCU security chip replies with the instruction to notify the Android system to start normally. If the verification fails, the Android system cannot start normally and actively initiates a power-off request instruction to the MCU security chip. Step S2: Connect the encrypted external storage device to the interface of the Android board. The MCU security chip will communicate with the external storage device. If the MCU security chip recognizes that the connected external storage device has been encrypted by the corresponding program and successfully decrypted using the corresponding algorithm, it will actively initiate the operation of starting the Android system. If the recognized external storage device is not encrypted or the decryption fails, the Android system cannot be started; Step S3: When the Android system is powered on and receives the startup command from the MCU security chip, it boots up normally and enters the system. After entering the system, the communication path of the external storage device is switched to the Android system. The Android system actively reads the content in the external storage device and determines whether the content has been encrypted by the supporting program. If it has been encrypted, it is decrypted using the supporting encryption and decryption algorithm. If the decryption is successful, the decrypted file is played. If the content is not encrypted or the decryption fails, the playback operation is not performed.
2. The method for securely starting and playing the contents of an external storage device according to claim 1, characterized in that: It also includes step S4: unplug the external storage device, the Android system will passively receive the uninstall broadcast of the external storage device, the Android system will send an instruction to the MCU security chip, informing it that the external storage device has been uninstalled and needs to be shut down. The MCU security chip starts a signal to power off the Android system to complete the shutdown operation of the Android system.
3. The method for securely starting and playing the contents of an external storage device according to claim 1, characterized in that: In step S1, the startup of the Android system is determined by the MCU security chip. The MCU security chip pulls up the power supply gpio control pin of the Android system, and the powered Android system starts to start and run. During the operation, it communicates with the MCU security chip through the I2C signal and sends an encryption instruction requesting normal startup. The MCU security chip processes the data sent by the Android system after receiving it. If the startup of the Android system is actively triggered by the MCU security chip, the MCU security chip replies to the data on the Android system side as an instruction to allow startup. If the startup of the Android system is not actively triggered by the MCU security chip, the MCU security chip replies to the data on the Android system side as an instruction not to allow startup.
4. The method for securely starting and playing the contents of an external storage device according to claim 1, wherein: After receiving the data replied by the MCU security chip, the Android system processes it. If the MCU security chip receives a startup permission instruction, it enters the system normally. If the MCU security chip receives a startup permission instruction, the Android system actively sends an instruction to the MCU security chip again to request a shutdown instruction. After receiving the shutdown request instruction, the MCU security chip actively pulls down the gpio control pin to power off the Android system.
5. The method for securely starting and playing the contents of an external storage device according to claim 1, characterized in that: Before connecting the external storage device with content to the Android board, it must first be connected to the PC. The encryption algorithm on the PC reads the important feature information of the storage device, generates data through the CRC algorithm, and writes it to generate an identification file A. A password is set for the content in the external storage device, and data is generated through the CRC algorithm and written to a file to generate an identification file B.
6. The method for securely starting and playing the contents of an external storage device according to claim 5, characterized in that: After the peripheral storage device is connected to the Android board, the MCU security chip first queries and parses the identification file A when reading the peripheral storage device, and compares and verifies the data in it. If the verification is successful, it means that this device is a compliant storage device. After the verification is successful, the MCU security chip actively starts the Android system. After the Android system starts, it reads the contents of the peripheral storage device, searches for the contents in the storage device, and identifies file B. If the queries are all found, it parses this identification file B, extracts the file names of all files and the corresponding file MD5 values, and then compares the MD5 values with the original files. If the comparison and verification pass, it means that the content is decrypted.
7. The method for securely starting and playing the contents of an external storage device according to claim 6, characterized in that: If the query finds that there is only a compressed package in the external storage device, it will determine whether a password needs to be filled in during decompression. If there is no prompt to fill in a password, it means that this package has not been encrypted by the supporting program and no processing will be performed. If it is determined that a password is required, a password verification will be performed. After the verification passes, the decompression operation will be performed. After the decompression is completed, the file names of all the contents and the md5 values of the corresponding files will be collected.
8. The method for securely starting and playing the contents of an external storage device according to claim 1, characterized in that: When the peripheral storage device is a USB flash drive, communication is carried out through the USB protocol. When the MCU security chip has not yet started the Android system, the default path of the USB Switch chip is the USB peripheral interface connected to the MCU security chip. When the Android system is powered on and receives the startup command from the MCU security chip, it will boot into the system normally. After entering the system, the Android system will pull up the gpio control pin of the USB Switch chip, switch the communication path to the Android side, and communicate with the Android system. The Android system will actively read the contents of the USB flash drive.
9. The method for securely starting and playing the contents of an external storage device according to claim 1, characterized in that: When the peripheral storage device is a TF / SD card, communication is carried out through the SDIO protocol. When the MCU security chip has not yet started the Android system, the default path of the SDIO Switch chip is to connect the TF / SD peripheral interface to the MCU security chip. When the Android system is powered on and receives the startup command from the MCU security chip, it will boot into the system normally. After entering the system, the Android system will pull up the gpio control pin of the SDIO Switch chip, switch the communication path to the Android side, and communicate with the Android system. The Android system will actively read the contents of the TF / SD card.