Storage card binding, verification and data access method and device

Abstract

The invention provides a binding, verification and data access method for a memory card of terminal equipment and corresponding equipment, and the scheme realizes triple binding among the memory card, a current login user and the terminal equipment through the memory card identification information, the user identification information and the equipment identification information during binding, establishes a stronger association relationship, and improves the user experience. Meanwhile, a double-layer password system of a master key and a data encryption key is adopted, the master key is dynamically generated based on triple-binding information, the data encryption key is independently managed, timestamp information for verification and a digital signature are further added on the basis, and a cloud collaborative management mechanism is combined, so that the data security is effectively improved; therefore, the user can access the user data in the memory card only after strict multiple verifications, and the risk of data leakage of the memory card is effectively solved.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method and device for binding, verifying, and accessing data of a memory card. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) and smart security devices, terminal devices such as smart doorbells, dashcams, and smart cameras increasingly use SD cards and other memory cards as local storage media to store user data such as videos, images, and configuration information. However, currently, memory cards generally lack an effective data security management mechanism. The same memory card can be freely switched between multiple devices. For example, any user can remove a memory card from device A and insert it into device B. This results in the user data stored on the memory card being arbitrarily read, posing a serious risk of data leakage. Summary of the Invention

[0003] One object of this application is to provide a method and device for binding, authenticating, and accessing data of a memory card.

[0004] To achieve the above objectives, this application provides a method for binding a memory card, the method comprising: When a memory card is detected, the physical information of the memory card is read, and the first memory card identification information is generated based on the physical information; Obtain the first user identifier information and the first device identifier information of the currently logged-in user of the terminal device; construct binding relationship data based on the first storage card identifier information, the first user identifier information, the first device identifier information and the timestamp information; and digitally sign the binding relationship data using the device private key to generate binding signature information. A first master key is generated based on the first storage card identification information, the first user identification information, and the first device identification information; The binding information and the data encryption key are encrypted using the first master key, wherein the binding information includes binding relationship data and binding signature information, and the data encryption key is a key used to encrypt user data written to the memory card; A hidden protection partition is created in the memory card, and the encrypted binding information and data encryption key are written into the hidden protection partition; Report the binding information to the cloud device.

[0005] Further, a first master key is generated based on the first storage card identification information, the first user identification information, and the first device identification information, including: A preset key generation algorithm is used to perform a preset number of iterative calculations on the first memory card identifier, the first user identifier, and the first device identifier to generate a first master key.

[0006] Further, a hidden protection partition is created in the memory card, and the encrypted binding information and data encryption key are written to the hidden protection partition, including: Create a hidden protection partition of a preset size in the starting sector of the memory card; The encrypted binding information and data encryption key are written to the hidden protection partition, and read-only and hidden attributes are set.

[0007] This application embodiment also provides a method for verifying a memory card, the method comprising: When a memory card is detected, the physical information of the memory card is read, and the second memory card identification information is generated based on the physical information; Check if the memory card has a hidden protection partition. If a hidden protection partition exists, read the encrypted binding information from the hidden protection partition. The encrypted binding information in the hidden protection partition is written using the aforementioned binding method. Obtain the second user identifier information and the second device identifier information of the currently logged-in user of the terminal device, and generate a second master key based on the obtained second storage card identifier information, second user identifier information and second device identifier information; Use the second master key to decrypt the encrypted binding information; If decryption is successful, the binding relationship data and binding signature information are extracted from the encrypted binding information. The binding relationship data includes the first storage card identification information, the first user identification information, the first device identification information, and the timestamp information. The device public key is used to verify the validity of the bound signature information and to check the rationality of the timestamp information; If both the validity check and the reasonableness check pass, the first memory card identifier, the first user identifier, and the first device identifier are matched with the second memory card identifier, the second user identifier, and the second device identifier, respectively, to obtain the identifier matching result; Based on the identifier matching result, determine whether the memory card has passed verification.

[0008] Furthermore, the method also includes: The first storage card identification information, the first user identification information, and the first device identification information are reported to the cloud device for blacklist checking; Based on the identifier matching result, it is determined whether the memory card has passed verification, including: Based on the identifier matching result and the blacklist check result, determine whether the memory card has passed verification.

[0009] Further, based on the identifier matching result and the blacklist check result, it is determined whether the memory card has passed verification, including: If all identifier matching results are correct and the blacklist check results are passed, the memory card verification is confirmed to be successful, and data access to the memory card is permitted.

[0010] Further, based on the identifier matching result and the blacklist check result, it is determined whether the memory card has passed verification, including: If both items in the identifier matching result match correctly and the blacklist check result passes, the memory card verification part is determined to be passed, allowing data access to a portion of the data in the memory card.

[0011] Furthermore, after confirming that the memory card verification process has passed, the process further includes: Authenticate the currently logged-in user on the terminal device; If authentication is successful, based on the second storage card identifier, the second user identifier, and the second device identifier, the encrypted binding information and data encryption key in the hidden protection partition, as well as the binding information of the cloud device, are updated, and the storage card is confirmed to have been verified.

[0012] Furthermore, the method also includes: If the number of authentication failures reaches a preset number, it is determined that the memory card authentication has failed, and data access to the memory card is prohibited.

[0013] Further, based on the identifier matching result and the blacklist check result, it is determined whether the memory card has passed verification, including: If fewer than two identifiers match correctly in the matching results, or if the blacklist check fails, the memory card verification is deemed to have failed, and data access to the memory card is prohibited.

[0014] Furthermore, after determining that the memory card verification failed, the process also includes: The cloud device is reported to trigger a security warning, so that the cloud device sends a security notification to the user bound to the storage card and generates an anomaly record for this verification. The anomaly record is used to update the blacklist used for blacklist checks. Format the memory card or uninstall the memory card.

[0015] Further, formatting the memory card includes: The secure erase algorithm is executed. The first pass writes 0x00 to the entire memory card, the second pass writes 0xFF to the entire memory card, and the third pass writes random data to the entire memory card. Rebuild the partition table of the memory card and create a preset standard file system; Notify the cloud device to clear the corresponding binding information.

[0016] This application embodiment also provides a data access method for a memory card, the method comprising: Using the aforementioned verification method, it was determined that the memory card passed verification; The encrypted data encryption key is decrypted using the second master key, and the encrypted data encryption key is read from the hidden protection partition; Use the data encryption key obtained through decryption to perform data access operations.

[0017] Furthermore, the method also includes: Based on the data access operation, the most recent access time of the storage card is recorded, and the timestamp information in the binding relationship data is updated based on the most recent access time.

[0018] Based on another aspect of this application, a terminal device is also provided, which includes a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein when the computer program instructions are executed by the processor, a binding method, a verification method, or a data access method of the memory card is triggered.

[0019] This application also provides a computer-readable medium storing computer program instructions that can be executed by a processor to implement the binding method, verification method, or data access method of the memory card.

[0020] Compared with existing technologies, this application provides a solution for binding, verifying, and accessing data on a memory card. During binding, this solution establishes a stronger connection between the memory card, the currently logged-in user, and the terminal device through triple binding using memory card identification information, user identification information, and device identification information. It also employs a two-layer cryptographic system consisting of a master key and a data encryption key. The master key is dynamically generated based on the triple binding information, while the data encryption key is managed independently. Furthermore, timestamp information and digital signatures for verification are added, combined with a cloud-based collaborative management mechanism, effectively improving data security. This ensures that users must undergo rigorous multi-level verification before accessing user data on the memory card, effectively mitigating the risk of data leakage from the memory card.

[0021] Furthermore, the solution provided in this application embodiment can also implement different security level classification processing strategies based on different verification results during verification. Under low risk, normal access to user data in the memory card is allowed; under medium risk, access to some non-sensitive data is allowed, and options such as authentication and binding information updates are provided; while under high risk, mandatory protection is implemented, and user data in the memory card is not allowed, thereby achieving a good balance between security and ease of use. Attached Figure Description

[0022] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a method for binding a memory card according to an embodiment of this application; Figure 2 A flowchart illustrating a method for verifying a memory card provided in an embodiment of this application; Figure 3 A schematic diagram of the overall system architecture for implementing memory card information protection using the solution provided in the embodiments of this application; Figure 4 The flowchart illustrates the process of initializing and binding a memory card using the binding scheme described in this application. Figure 5 This is a flowchart illustrating the process of verifying a memory card using the verification scheme described in this application. Figure 6 This is a flowchart illustrating the normal access process after the memory card verification is successful in this embodiment of the application. Figure 7 This is a flowchart illustrating the medium-risk processing procedure after the memory card verification in this embodiment of the application has been passed. Figure 8 This is a flowchart illustrating the high-risk handling process after the memory card verification fails, as described in this application embodiment. The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0023] The present application will now be described in further detail with reference to the accompanying drawings.

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0026] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0027] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0028] This application provides a method for binding, verifying, and accessing data on a memory card. During binding, the method establishes a stronger connection between the memory card, the currently logged-in user, and the terminal device through memory card identification information, user identification information, and device identification information. It also employs a two-layer cryptographic system consisting of a master key and a data encryption key. The master key is dynamically generated based on the triple-binding information, while the data encryption key is managed independently. Furthermore, timestamp information and digital signatures for verification are added, combined with a cloud-based collaborative management mechanism, effectively improving data security. This ensures that users must undergo rigorous multi-factor authentication before accessing user data on the memory card, effectively mitigating the risk of data leakage from the memory card.

[0029] In real-world scenarios, the execution subject of the method can be any terminal device that can use a memory card. These terminal devices may include, but are not limited to, computers, mobile phones, tablets, smart doorbells, dashcams, smart cameras, drones, action cameras, and other similar devices.

[0030] Figure 1 The present application illustrates a processing flow of a memory card binding method according to an embodiment of the present application, which includes at least the following processing steps: Step S101: When a memory card is detected, read the physical information of the memory card and generate the first memory card identification information based on the physical information.

[0031] When a memory card is inserted into a terminal device, the device detects it and can then read its physical information. This information may include, for example, CID (Card Identification Number), serial number, capacity, manufacturer ID, or any other information that can distinguish different memory cards. After obtaining this physical information, a first memory card identifier is generated to uniquely identify the memory card. In practical scenarios, generating the first memory card identifier using physical information can employ a hash calculation method. The CID, serial number, capacity, manufacturer ID, and other physical information are combined in a specific order, and then a preset hash function is used to calculate the hash value, which is then used as the first memory card identifier.

[0032] Step S102: Obtain the first user identifier information and the first device identifier information of the currently logged-in user of the terminal device.

[0033] The currently logged-in user of the terminal device is the user currently using the terminal device. For example, taking a smart doorbell as an example, if the currently logged-in and user of the smart doorbell is user1, then user1's user ID can be used as the first user identification information, so that a user can be uniquely identified through the first user identification information. The first device identification information refers to information that can uniquely identify the terminal device. For example, it can also be obtained by combining the physical information of the terminal device, such as serial number, MAC (Media Access Control) address, and chip ID, and then performing a hash calculation.

[0034] Step S103: Based on the first storage card identification information, the first user identification information, the first device identification information, and the timestamp information, construct binding relationship data, and use the device private key to digitally sign the binding relationship data to generate binding signature information.

[0035] When constructing the binding relationship data, the first storage card identifier, the first user identifier, and the first device identifier can be used to uniquely identify the storage card, the user, and the terminal device, respectively. This enables a triple binding between the storage card, the currently logged-in user, and the terminal device, establishing a stronger association. Simultaneously, timestamp information is added to record the most recent update time of the binding relationship data, facilitating time verification to check the time's validity and prevent replay attacks, thus further enhancing security as a security verification mechanism.

[0036] Therefore, after binding and establishing the association relationship by combining the first storage card identifier information, the first user identifier information, the first device identifier information, and the timestamp information, the binding relationship data CardID_Bind + UserID_Bind + DeviceID_Bind + TimeStamp can be obtained. Then, the binding relationship data can be digitally signed using the device private key to generate binding signature information. For example, the signature algorithm used in this embodiment can be RSA2048. The resulting binding signature information can be used to check the signature validity during verification, or it can serve as a security verification mechanism to further enhance security.

[0037] Furthermore, when building and binding relationships, geographical location information and / or user behavior pattern information can be added. For example, in practical scenarios, GPS information or IP address can be used as geographical location information to bind with the first storage card identifier, the first user identifier, and the first device identifier; or user behavior pattern information such as operating habits and usage time periods can be bound with the first storage card identifier, the first user identifier, and the first device identifier to build more complex binding relationship data and improve data security.

[0038] Step S104: Generate a first master key based on the first memory card identifier, the first user identifier, and the first device identifier. The master key is a KEK (Key Encryption Key) used to encrypt the data encryption key (DEK).

[0039] In this embodiment, a preset key generation algorithm is used to perform a preset number of iterative calculations on the first memory card identifier, the first user identifier, and the first device identifier to generate a first master key. For example, the preset key generation algorithm can be the PBKDF2HMACSHA256 algorithm. After iteratively calculating the triple ID composed of the first memory card identifier, the first user identifier, and the first device identifier 100,000 times using the preset key generation algorithm, a 256-bit string is generated, which can be used as the first master key in this scheme.

[0040] Step S105: Encrypt the binding information and the data encryption key using the first master key. The binding information includes at least the binding relationship data CardID_Bind + UserID_Bind + DeviceID_Bind + TimeStamp and the binding signature information Signature. In practical scenarios, it may also include other necessary metadata, such as version number and algorithm identifier. The data encryption key is used to encrypt user data written to the memory card and can be generated in any pre-defined manner. For example, in this embodiment, a hardware random number generator can be used to generate a 256-bit string as the data encryption key DEK.

[0041] Step S106: Create a hidden protection partition in the memory card, and write the encrypted binding information and data encryption key into the hidden protection partition. The information written into the hidden protection partition can only be read and cannot be modified. It is used as the benchmark data for verification in subsequent verification processes to achieve multiple security verifications, thereby ensuring the security of user data in the memory card.

[0042] In some embodiments of this application, a hidden protection partition of a preset size can be created in the starting sector of the memory card. For example, the size of the hidden protection partition can be set to 1MB, and the partition type can be 0xE8. After creation, the encrypted binding information and data encryption key are written to the hidden protection partition, and read-only and hidden attributes are set to prevent the information in the hidden protection partition from being read or modified at will.

[0043] Step S107: Report the binding information to the cloud device. By uploading the binding information to the cloud device, a record can be established between the user, the terminal device, and the memory card in the cloud, facilitating subsequent blacklist checks and other security functions, thereby further enhancing security.

[0044] After successfully uploading to the cloud, relevant information can be returned, displaying a message indicating successful initialization, so that users can clearly understand the current binding status of the memory card.

[0045] Based on the completion of memory card binding, this application embodiment also provides a memory card verification method, the processing flow of which is as follows: Figure 2 As shown, it includes at least the following processing steps: Step S201: When a memory card is detected, read the physical information of the memory card and generate the second memory card identification information based on the physical information.

[0046] When a memory card is inserted into a terminal device, the terminal device detects the memory card and can then read the physical information of the memory card. Using this physical information, a second memory card identification information can be generated that can uniquely identify the memory card.

[0047] The second and first memory card identification information are both generated based on the physical information of the memory card to uniquely identify the memory card. They are essentially the same, but are used to distinguish different processing stages. The second memory card identification information CardID_Current is generated when the physical information of the memory card is read during the verification stage, while the first memory card identification information CardID_Bind is generated when the physical information of the memory card is read during the binding stage.

[0048] Step S202: Check if the memory card has a hidden protection partition. If a hidden protection partition exists, read the encrypted binding information from the hidden protection partition.

[0049] For already bound memory cards, a hidden protection partition exists, and encrypted binding information has been written into this partition using the aforementioned binding method. For unbound memory cards, since there is no hidden protection partition, the binding process can be redirected to the aforementioned binding method to bind the memory card.

[0050] Step S203: Obtain the second user identifier information UserID_Current and the second device identifier information DeviceID_Current of the currently logged-in user of the terminal device, and generate a second master key based on the obtained second storage card identifier information, second user identifier information and second device identifier information.

[0051] Similarly, the relationship between the second user identifier information, the second device identifier information, the second master key and the first user identifier information, the first device identifier information, and the first master key is similar to the relationship between the second memory card identifier information and the first memory card identifier information. The latter three are obtained or generated in the same way as the former three, and are only used to facilitate the distinction between the binding stage and the verification stage.

[0052] When generating the second master key, the generation algorithm is the same as that used when generating the first master key, to ensure that the same master key can be generated based on the same memory card identification information, user identification information, and device identification information.

[0053] Step S204: Decrypt the encrypted binding information using the second master key.

[0054] Since the second master key is generated based on the second memory card identifier, the second user identifier, and the second device identifier obtained during verification, if the first memory card identifier, the first user identifier, and the first device identifier that generate the first master key during the binding phase are all the same as the second memory card identifier, the second user identifier, and the second device identifier, then the generated second master key will also be the same as the first master key used to encrypt the binding information during the binding phase.

[0055] Therefore, decryption can only succeed if the first memory card identifier, first user identifier, and first device identifier in the binding information match the second memory card identifier, second user identifier, and second device identifier read at this time. If decryption fails, the second master key does not match, indicating that the memory card identifier, user identifier, and device identifier read at this time have changed since the binding process. This poses a certain security risk and can be considered a failure of memory card verification.

[0056] Step S205: If decryption is successful, extract the binding relationship data and binding signature information from the encrypted binding information. The binding relationship data includes first memory card identifier information, first user identifier information, first device identifier information, and timestamp information. Upon successful decryption, the decrypted binding information can be obtained, from which the binding relationship data and binding signature information generated during the memory card binding stage can be retrieved.

[0057] Step S206: Verify the validity of the binding signature information using the device public key, and check the rationality of the timestamp information.

[0058] Since the binding signature information is obtained by digitally signing the device's private key, the validity of the binding signature information can be verified using the device's public key. If the binding relationship data has not been tampered with, the validity verification can be passed.

[0059] The timestamp information in the binding relationship data can be used to verify the reasonableness of the time. Specifically, the reasonableness check of the timestamp information can be performed by selecting any combination of the following rules, depending on the actual needs of the scenario: Rule 1: Timestamp information must not be later than the current time to prevent future timestamps. In practical scenarios, a certain margin of error can be set, for example, a 5-minute error can be tolerated, as long as the timestamp is no later than the current time + 5 minutes.

[0060] Rule 2: Timestamp information must not be too outdated to prevent expired binding relationships. For example, in this embodiment, the timestamp information can be set to be within one year prior to the current time, meaning the binding relationship is valid for one year.

[0061] Rule 3: Check time backtracking to prevent replay attacks. Timestamp information uses a monotonically increasing format. Checking the monotonically increasing timestamp identifier helps prevent replay attacks.

[0062] Rule 4: System clock reliability verification. Check the reliability of the system clock. If the system clock is unreliable, other methods need to be used for processing.

[0063] Rule 5: Consistency between timestamp information and signature time. If the digital signature includes a signature time, the consistency between the timestamp and the signature time can be checked. In practical scenarios, a certain margin of error can also be set, for example, a one-minute error can be tolerated, as long as the difference between the timestamp and the signature time does not exceed one minute.

[0064] Step S207: If both the validity check and the reasonableness check pass, the first memory card identifier information, the first user identifier information, and the first device identifier information are matched with the second memory card identifier information, the second user identifier information, and the second device identifier information, respectively, to obtain the identifier matching result.

[0065] During matching, the first memory card identifier information CardID_Bind can be compared with the second memory card identifier information CardID_Current, the first user identifier information UserID_Bind can be compared with the second user identifier information UserID_Current, and the first device identifier information DeviceID_Bind can be compared with the second device identifier information DeviceID_Current, and the matching degree can be calculated. The matching degree Score = (UserID matching ≥ 1:0) + (DeviceID matching ≥ 1:0) + (CardID matching ≥ 1:0).

[0066] Therefore, if all three identifiers match correctly, the matching score is 3; if two of the identifiers match correctly, the matching score is 2; if one of the identifiers matches correctly, the matching score is 1; and if all the identifiers match incorrectly, the matching score is 0.

[0067] Step S208: Based on the identifier matching results, determine whether the memory card has passed verification. In this embodiment, different identifier matching results can correspond to different verification results. For example, in this embodiment, if all three identifier matching results are correct, the memory card verification is confirmed to be successful. Therefore, the solution of this application embodiment provides a strict multi-verification mechanism to verify the memory card. After the memory card is inserted into the terminal device, only after passing this verification process can the user data in the memory card be accessed, effectively solving the risk of data leakage from the memory card.

[0068] In some embodiments of this application, the method can also report the first memory card identifier information, the first user identifier information, and the first device identifier information to a cloud device for blacklist checking. Thus, based on the identifier matching results and the blacklist check results, it can be determined whether the memory card has passed verification, further improving security.

[0069] In practical scenarios, the blacklist check can be based on memory card blacklists, device blacklists, user blacklists, binding relationship blacklists, and IP / geographic location blacklists. For example, the memory card blacklist can include the memory card identification information of stolen memory cards, cloned memory cards, and memory card identification information of memory cards exhibiting abnormal behavior. The device blacklist can include the device identification information of stolen devices, malicious devices, and devices violating regulations. The user blacklist can include the user identification information of users who violate regulations, users with outstanding payments, and malicious users. The binding relationship blacklist can include abnormal binding relationships and reported binding relationships. The IP / geographic location blacklist can include malicious IP addresses and high-risk geographical locations.

[0070] If the information reported this time does not exist in these blacklists, then the blacklist check can be confirmed. This method of blacklist checking can effectively eliminate relevant risks and further improve security.

[0071] In the solution of this application embodiment, when determining whether the memory card has passed verification based on the identifier matching result and the blacklist check result, the verification result can be divided into the following three types: 1. If all identifier matching results are correct and the blacklist check result is passed, the storage card verification is confirmed, and data access to the storage card is permitted. In this case, the matching score is 3, and the blacklist check result of the cloud device is passed, the storage card verification is successful, and the data in the storage card can be accessed normally.

[0072] 2. If both items in the identifier matching result match correctly and the blacklist check result passes, the storage card verification is deemed successful, allowing access to some data on the storage card. In this case, the matching score is 2, and the cloud device's blacklist check result passes. Although the storage card verification fails, the risk is relatively controllable. Access to some non-sensitive data on the storage card is permitted, and some medium-risk related processing, such as identity verification, can be performed.

[0073] 3. If fewer than two matches are correct in the identifier matching results, or if the blacklist check fails, the storage card verification is deemed unsuccessful, and data access to the storage card is prohibited. In this case, the matching score is ≤1, and the cloud device's blacklist check fails, resulting in storage card verification failure. The user will be unable to access any data on the storage card, and some high-risk procedures will be performed, such as sending warning messages or formatting the storage card.

[0074] If the memory card verification is successful, this application embodiment also provides a data access method for the memory card. This method first uses the aforementioned verification method to confirm that the memory card verification is successful. Then, a second master key is used to decrypt the encrypted data encryption key. Finally, the decrypted data encryption key is used to perform a data access operation. The encrypted data encryption key is read from the hidden protection partition.

[0075] The data access operation includes writing, deleting, or modifying user data into the storage card. Each data access operation has a corresponding access time. Therefore, the most recent access time of the storage card can be recorded based on the data access operation, and the timestamp information in the binding relationship data can be updated based on the most recent access time, thereby updating the binding relationship in real time based on the actual data access.

[0076] In addition, it can monitor abnormal behavior during the use of the memory card, upload data to the cloud device for updating the blacklist, and record verification logs, including information such as time, user ID, device ID, and SD card identifier.

[0077] If the memory card verification passes, authentication can be performed with the currently logged-in user on the terminal device. For example, in practical scenarios, authentication options can be provided to the user, including cloud account password verification, biometric verification, and SMS verification code verification. If authentication is successful, based on the second memory card identifier, the second user identifier, and the second device identifier, the encrypted binding information and data encryption key in the hidden protection partition, as well as the binding information of the cloud device, are updated. After the update is complete, the memory card verification is considered successful, and data access to the memory card is then permitted.

[0078] In a real-world scenario, after successful user authentication, the user can be asked whether they trust the current environment. If the user chooses to trust, the original binding information can be backed up first, and then the binding information can be regenerated using the second storage card identifier, second user identifier, and second device identifier to update the encrypted binding information and data encryption key in the hidden protection partition, as well as the binding information of the cloud device. If the user chooses not to trust, the storage card can be formatted.

[0079] In addition, this embodiment can first determine the type of mismatch in the identifier matching results, such as user identifier information mismatch (which may be due to account changes or family sharing), device identifier information mismatch (which may be due to device repair and motherboard replacement), memory card identifier information mismatch (which may be due to physical damage to the memory card), etc. Based on this, a risk warning interface is displayed to the user, explaining the detected mismatch, and entering a restricted access mode, which only allows reading non-sensitive user data, such as file lists and shooting times, while prohibiting access to sensitive user data such as videos and pictures.

[0080] In some embodiments of this application, if the number of authentication failures reaches a preset number, it is determined that the memory card authentication has failed, and data access to the memory card is prohibited. For example, if a user fails to authenticate three times, it can be considered that the memory card authentication has failed, thus jumping to the high-risk handling process for failed authentication and prohibiting data access to the memory card.

[0081] If the memory card verification fails, data access to the memory card will be immediately prohibited to prevent the leakage of any sensitive data and ensure data security. Simultaneously, the device will report to the cloud device to trigger a security warning. This will cause the cloud device to send a security notification to the user associated with the memory card and generate an anomaly record for the verification. This anomaly record is used to update the blacklist used for blacklist checks. Finally, the memory card will be formatted or uninstalled.

[0082] The anomaly logs for this verification can be detailed logs of high-risk events, specifically including event time, geographical location, current binding information, binding information recorded in the hidden protected partition, and reasons for verification failure. Information from these anomaly logs can be used to update the blacklist used for blacklist checks, enabling more accurate blacklist checks in the future. For example, if the same memory card triggers anomaly logs multiple times within a preset period, that memory card will be added to the memory card blacklist.

[0083] When a device reports a security warning triggered by a cloud device, the cloud device can send security notifications to the bound user via app push notifications, SMS, email, etc., such as "Your memory card has been detected being used on an unauthorized device. Please confirm immediately" or "An SD card has been detected being bound to another user and device. To protect data security, it must be formatted before it can be used." Simultaneously, the user can be provided with two options: format the memory card or uninstall it, and appropriate actions can be taken based on the user's choice.

[0084] In the embodiments of this application, when formatting the memory card, a secure erase algorithm can be executed. The first pass writes 0x00 to the entire memory card, the second pass writes 0xFF to the entire memory card, and the third pass writes random data to the entire memory card. The partition table of the memory card is rebuilt, a preset standard file system is created, and the cloud device is notified to clear the corresponding binding information.

[0085] In a real-world scenario, a formatting confirmation interface can be displayed to the user before formatting, including the prompt message "Formatting will erase all data on the memory card, including videos, pictures, and configuration information, and is irreversible. Do you want to continue?". After the user confirms formatting, a secure erase algorithm conforming to the DoD 5220.22-M standard is executed. This algorithm writes 0x00 to the entire memory card in the first pass, 0xFF in the second pass, and random data in the third pass. Then, the partition table can be rebuilt, and a standard FAT32 or exFAT file system can be created, thereby clearing the hidden protection partition and all binding information already written to it, marking the memory card as uninitialized. At this point, the user can be asked whether to immediately initialize the binding. If the user confirms, the aforementioned binding method is executed to complete the binding of the memory card. Throughout the formatting operation, operation logs can be recorded and uploaded to a cloud device for storage, supporting post-event auditing and traceability, and facilitating security incident investigations.

[0086] Figure 3 The present invention illustrates the overall system architecture for protecting memory card information using the solution provided in this application embodiment. The system includes a terminal device 100, a memory card 200, and a cloud device 300. The cloud device 100 includes: a triple binding generation module 110, a hierarchical encrypted storage module 120, an intelligent verification module 130, a risk classification processing module 140, a secure data migration module 150, and a cloud collaborative management module 160.

[0087] The triple binding generation module 110 is used to perform the following functions: User ID Acquisition Unit: Acquires the user identification information of the currently logged-in user from the device cloud account system; Device ID Acquisition Unit: Acquires device identification information of the terminal device, including a combined hash value of the device serial number, MAC address, and chip ID; Memory card identification acquisition unit: Reads information such as the memory card's CID, serial number, capacity, and manufacturer ID, and generates memory card identification information; Binding relationship establishment unit: Combines user identification information, device identification information, memory card identification information, and timestamp information to generate binding relationship data; Digital signature unit: Uses the device's private key to digitally sign the binding relationship data, ensuring the integrity and immutability of the binding relationship data.

[0088] The hierarchical encrypted storage module 120 is used to achieve the following functions: Key generation unit: Based on user identification information, device identification information, and memory card identification information, a 256-bit master key KEK (Key Encryption Key) is generated using the PBKDF2-HMAC-SHA256 algorithm (100,000 iterations). Data Encryption Key Generation Unit: Uses a hardware random number generator to generate a 256-bit data encryption key DEK (Data Encryption Key), and uses KEK to encrypt and store the DEK; Binding information encryption unit: The binding information is encrypted using the AES-256-CBC algorithm and written to the hidden protection partition of the memory card; User data encryption unit: The AES-256-GCM algorithm is used to encrypt and store user data such as video recordings and pictures. Each file uses an independent initialization vector. Hidden Protection Partition Creation Unit: Creates a 1MB hidden protection partition (partition type identifier 0xE8) in the starting sector of the memory card, stores encrypted binding information and encrypted DEK, and sets read-only and hidden attributes.

[0089] The intelligent verification module 130 is used to implement the following functions: Physical detection unit: detects memory card insertion events and reads the physical information of the memory card; Initialization status judgment unit: Checks whether it is a new card that is not bound or a card that is already bound; Binding information reading unit: Reads encrypted binding information and DEK from the hidden protected partition of the memory card; Binding Information Decryption Verification Unit: Regenerates KEK using the current user identification information, device identification information, and memory card identification information, attempts to decrypt the read binding information, and verifies the validity of the digital signature; Triple matching verification unit: Matches the user identification information read from the memory card with the user identification information of the currently logged-in user, matches the device identification information read from the memory card with the device identification information of the current device, and matches the memory card identification information read from the memory card with the actual memory card identification information of the memory card, and calculates the matching score (0-3 points). Timestamp verification unit: Verifies the validity of the bound time and detects time backtracking attacks; Cloud verification unit: The binding information is reported to the cloud for blacklist checking to see if it is on the cloud blacklist.

[0090] The risk classification processing module 140 is used to implement the following functions: Risk Level Assessment Unit: The risk level is assessed based on the matching score and verification result: Score=3 and verification passed by the cloud blacklist indicates successful verification; Score=2 and verification passed by the cloud blacklist indicates medium risk; Score≤1 or signature verification failed indicates high risk. Successful verification processing unit: decrypts DEK and user data, mounts SD card file system, allows normal read and write, and records success log; Medium-risk handling unit: Enters restricted access mode, only allowing reading of non-sensitive metadata, providing authentication options (cloud account password, biometrics, SMS verification code), and after successful verification, you can choose to update the binding relationship or format it; High-risk handling unit: Immediately prohibits access to the memory card, records high-risk logs and reports them to the cloud, sends security notifications to the bound user, displays high-risk warnings, and guides the user to format or exit; Formatting processing unit: Displays the formatting confirmation interface, performs a secure erase conforming to the DoD 5220.22-M standard (three overwrites: 0x00, 0xFF, and a random number), rebuilds the partition table, and clears all binding information; Log recording unit: Records all verification failure events, including time, user ID, device ID, SD card identifier, reason for failure, etc., and reports them to the cloud for security auditing.

[0091] The secure data migration module 150 is used to perform the following functions: User authentication unit: Strong authentication of user identity through two-factor authentication of password + SMS verification code; Data backup unit: With user authorization, decrypts the memory card data and encrypts it using the user's exclusive key to back it up to temporary cloud storage (valid for 24 hours). Binding relationship update unit: After user confirmation, the old binding relationship is released and a new triple binding relationship is established; Data recovery unit: Recovers user data on the new memory card, re-encrypts it using the new DEK, and verifies data integrity; Old data erasure unit: After confirming successful data migration, the old memory card is formatted.

[0092] The cloud-based collaborative management module 160 is used to implement the following functions: Binding relationship storage unit: Stores the triple binding relationship of all devices in a cloud database, supporting real-time synchronization; Anomaly monitoring unit: detects abnormal behaviors such as the same memory card being bound to multiple devices in a short period of time, or the memory card being frequently changed on the same device; Blacklist Management Unit: Manages blacklists of memory cards, devices, and users marked as risky, and automatically adds them to the blacklist after multiple high-risk events are triggered; Remote control unit: Supports users to remotely unbind, lock memory cards, and perform other operations via the cloud; Security Audit Unit: Records all security events such as binding changes, verification failures, and abnormal access, supporting post-event auditing and tracing.

[0093] Figure 4 The process flow for initializing and binding a memory card using the binding scheme in this embodiment is illustrated. The memory card used in this embodiment is an SD card (Secure Digital Memory Card). The specific process is as follows: Step S401: A new SD card has been detected.

[0094] Step S402: Read the physical information of the SD card, including CID, serial number, capacity, and manufacturer ID, and generate unique memory card identification information for the SD card.

[0095] Step S403: Determine if there is encrypted binding information on the memory card. If so, the SD card is already bound, and proceed to the verification process.

[0096] Step S404: If not, obtain the user ID of the currently logged-in user as the user identification information.

[0097] Step S405: Obtain the device's serial number, MAC address, and chip ID, and generate device identification information.

[0098] Step S406: Combine timestamp information to construct triple binding relationship data: user identifier information + device identifier information + memory card identifier information + timestamp information.

[0099] Step S407: Use the device private key to perform an RSA-2048 digital signature on the triple binding relationship data.

[0100] Step S408: Use the PBKDF2-HMAC-SHA256 algorithm (based on user identification information, device identification information and memory card identification information, iterated 100,000 times) to generate a 256-bit master key KEK.

[0101] Step S409: Use a hardware random number generator to generate a 256-bit data encryption key DEK.

[0102] Step S410: Encrypt DEK using KEK.

[0103] Step S411: Use KEK to encrypt the binding information.

[0104] Step S412: Create a 1MB hidden protected partition (partition type 0xE8) in the starting sector of the SD card.

[0105] Step S413: Write the encrypted binding information and the encrypted DEK, and set the read-only and hidden attributes.

[0106] Step S414: Report the binding information to the cloud to establish a cloud record.

[0107] Step S415: Display a message indicating successful initial binding.

[0108] Figure 5 The following is a flowchart illustrating the process of verifying a memory card using the verification scheme in this embodiment. The memory card used in this embodiment is an SD card, and the specific process is as follows: Step S501: A new SD card has been detected.

[0109] Step S502: Read the physical information of the SD card, including CID, serial number, capacity, and manufacturer ID, and generate unique memory card identification information for the SD card.

[0110] Step S503: Check if there is a hidden protected partition on the SD card. If not, it is determined that the new card has not been initialized and proceed to the initialization and binding process. Step S504: If it exists, read the encrypted binding information and the encrypted DEK from the hidden protection partition.

[0111] Step S505: Obtain the user identification information and device identification information of the currently logged-in user.

[0112] Step S506: Regenerate the master key KEK using the user identifier information, device identifier information, and memory card identifier information obtained this time.

[0113] Step S507: Attempt to decrypt the binding information using KEK. If decryption fails, it is determined that the key does not match, and the process is transferred to a high-risk handling procedure.

[0114] Step S508: If decryption is successful, extract the user identification information, device identification information, and memory card identification information from the binding information.

[0115] Step S509: Verify the validity of the digital signature in the binding information. If the signature verification fails, proceed to the high-risk processing procedure.

[0116] Step S510: Perform triple matching verification and calculate the matching score.

[0117] Step S511: Verify the validity of the timestamp information in the binding information.

[0118] Step S512: Report to the cloud device for secondary verification and check the blacklist; Step S513: Based on the matching score and the cloud blacklist results, perform different processing steps as follows: If Score=3 and the cloud blacklist check passes, the storage card verification is successful, and the normal access process begins.

[0119] If the score is 2 and the cloud blacklist check passes, the storage card verification process passes and the process is transferred to the intermediate risk handling procedure.

[0120] If the score is ≤1 or the blacklist check fails, the memory card verification fails and the process is transferred to the high-risk handling procedure.

[0121] Figure 6 The normal access process after successful memory card verification is shown, including the following steps: Step S601: Use KEK to decrypt the encrypted DEK to obtain the data encryption key DEK.

[0122] Step S602: Decrypt user data using DEK.

[0123] Step S603: Use the mounted SD card file system.

[0124] Step S604: Allow the device to read and write normally.

[0125] Step S605: Record the successful verification log, including time, user ID, device ID, and SD card memory card identification information.

[0126] During normal use, the timestamp information in the binding information will be updated regularly to record the last access time, and abnormal behavior during SD card use will be monitored.

[0127] Figure 7 The following steps illustrate the medium-risk handling process after the memory card verification is passed: Step S701: Determine the type of mismatched ID: user identification information mismatch only (may be due to account change or family sharing), device identification information mismatch only (may be due to device repair and motherboard replacement), or memory card identification information mismatch only (may be due to physical damage to the SD card).

[0128] Step S702: Display a risk warning interface to the user, explaining the detected mismatch.

[0129] Step S703: Enter restricted access mode, allowing only reading of non-sensitive data, such as file lists and shooting times, while prohibiting access to sensitive data such as videos and images; Step S704 provides identity verification options, such as cloud account password verification, biometric verification, and SMS verification code verification.

[0130] Step S705: Determine whether the authentication was successful.

[0131] Step S706: If user authentication is successful, ask whether to trust the current environment and update the binding information. Step S707: If the user confirms trust, back up the original binding information to the cloud, regenerate the binding information using the current user identification information, device identification information, and storage card identification information, update the binding information of the SD card hidden protection partition and the cloud device, and switch to the normal access process.

[0132] In step S708, if the user chooses not to trust, the memory card will be formatted.

[0133] In step S709, if identity verification fails three times, proceed to the high-risk handling process. During the medium-risk handling process, record the medium-risk event log and report it to the cloud.

[0134] Figure 8 This document illustrates a high-risk handling process following a failed memory card verification, including the following steps: Step S801: Immediately prohibit access to any data on the SD card.

[0135] Step S802: Record detailed logs of high-risk events (event time, geographical location, current binding information, binding information written to the storage card, and reason for failure). Step S803: Immediately report to the cloud security center and trigger a security alert; Step S804: The cloud sends a security notification to the bound user.

[0136] Step S805 provides two options: format or exit. If the user chooses to format, the formatting process is performed; if the user chooses to exit, the SD card is unmounted and the process ends.

[0137] The system marks abnormal access records of the SD card and the current device in the cloud. If the same SD card triggers high-risk events multiple times in a short period of time, it will be added to the blacklist.

[0138] In summary, the memory card binding, verification, and data access scheme provided in this application embodiment has at least the following beneficial effects: 1. Triple binding mechanism for enhanced security: The triple binding mechanism, which uses user identification information, device identification information, and memory card identification information, establishes a stronger association. If any verification fails, the protection mechanism will be triggered, significantly improving security compared to a single binding method.

[0139] 2. Layered encryption protection and scientific key management: It adopts a two-layer key system of KEK encryption and DEK encryption. The master key is dynamically generated based on triple ID, and the data key is managed independently. Even if the memory card is physically read, the data cannot be decrypted without the correct combination of user, device and memory card identification information.

[0140] 3. Intelligent verification mechanism with a user-friendly experience: A tiered processing strategy is implemented based on the matching score (0-3 points) and risk level. Low-risk users are allowed to continue using the service, medium-risk users are provided with authentication and binding update options, and high-risk users are subject to mandatory protection, achieving a good balance between security and ease of use.

[0141] 4. Digital signature anti-tampering: Digital signatures are applied to the binding relationship data to ensure the integrity and immutability of the binding relationship. Attackers cannot bypass the verification by modifying the binding information.

[0142] 5. Cloud-based collaborative management and global monitoring: The cloud provides unified management of the binding relationships of all devices, detects abnormal binding behavior (such as the same memory card being bound to different devices multiple times in a short period of time), enables blacklist management and remote control, and forms an integrated end-to-end security protection system.

[0143] 6. Supports legitimate data migration: Provides a secure data migration mechanism. When users change devices or memory cards, they can securely migrate data and update binding relationships through identity verification (password + SMS verification code) and cloud relay, avoiding data loss.

[0144] 7. Thorough and secure erasure: Performs a three-pass overwrite (0x00, 0xFF, random number) operation on the memory card to be formatted, conforming to the DoD 5220.22-M standard, to ensure that the data is completely erased and cannot be recovered by data recovery tools.

[0145] 8. Complete audit logs: Record detailed logs of all binding, verification, exception, formatting and other operations, including time, geographical location, user identification information, device identification information, memory card identification information, operation results, etc., supporting post-event auditing and tracing, and facilitating security incident investigation.

[0146] 9. Defense against multiple attacks: It can effectively defend against various security threats such as memory card cloning attacks, man-in-the-middle attacks, replay attacks, time rewind attacks, and brute-force attacks. Its security has been fully verified.

[0147] 10. Wide applicability: It is suitable for various terminal devices that use memory cards, such as smart doorbells, dashcams, smart cameras, drones, and action cameras. It has good versatility and scalability and can be widely used in the entire smart security industry.

[0148] Based on the same inventive concept, this application also provides a terminal device for protecting memory card information. The method corresponding to this device is the memory card binding, verification, or data access method in the aforementioned embodiments, and its problem-solving principle is similar to that method. The computing device provided in this application includes a memory for storing computer program instructions and a processor for executing the computer program instructions. When the computer program instructions are executed by the processor, the device is triggered to implement the methods and / or technical solutions of the aforementioned embodiments of this application.

[0149] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by a processing unit, it performs the functions defined in the methods of this application.

[0150] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0151] In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0152] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0153] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0154] In another aspect, this application also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The aforementioned computer-readable medium carries one or more computer program instructions, which may be executed by a processor to implement the methods and / or technical solutions of the various embodiments of this application.

[0155] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, a magnetic or optical drive, a floppy disk, or similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0156] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order. The numerical order of the sequence numbers corresponding to the steps does not indicate any particular execution order; the steps may be executed in any combination of orders provided that the execution logic is followed.

Claims

1. A method for binding a memory card, characterized in that, The method includes: When a memory card is detected, the physical information of the memory card is read, and a first memory card identification information is generated based on the physical information; Obtain the first user identifier information and the first device identifier information of the currently logged-in user of the terminal device; construct binding relationship data based on the first storage card identifier information, the first user identifier information, the first device identifier information and the timestamp information; and digitally sign the binding relationship data using the device private key to generate binding signature information. A first master key is generated based on the first storage card identification information, the first user identification information, and the first device identification information; The binding information and the data encryption key are encrypted using the first master key, wherein the binding information includes binding relationship data and binding signature information, and the data encryption key is a key used to encrypt user data written to the memory card; A hidden protection partition is created in the memory card, and the encrypted binding information and data encryption key are written into the hidden protection partition; Report the binding information to the cloud device.

2. The method according to claim 1, characterized in that, A first master key is generated based on the first memory card identifier, the first user identifier, and the first device identifier, including: A preset key generation algorithm is used to perform a preset number of iterative calculations on the first memory card identifier, the first user identifier, and the first device identifier to generate a first master key.

3. The method according to claim 1, characterized in that, Creating a hidden protected partition in the memory card and writing the encrypted binding information and data encryption key into the hidden protected partition includes: Create a hidden protection partition of a preset size in the starting sector of the memory card; The encrypted binding information and data encryption key are written to the hidden protection partition, and read-only and hidden attributes are set.

4. A method for verifying a memory card, characterized in that, The method includes: When a memory card is detected, the physical information of the memory card is read, and a second memory card identification information is generated based on the physical information; Check whether the memory card has a hidden protection partition. If a hidden protection partition exists, read the encrypted binding information from the hidden protection partition. The encrypted binding information in the hidden protection partition is written using the method described in any one of claims 1 to 3. Obtain the second user identifier information and the second device identifier information of the currently logged-in user of the terminal device, and generate a second master key based on the obtained second storage card identifier information, second user identifier information and second device identifier information; Use the second master key to decrypt the encrypted binding information; If decryption is successful, the binding relationship data and binding signature information are extracted from the encrypted binding information. The binding relationship data includes the first storage card identification information, the first user identification information, the first device identification information, and the timestamp information. The device public key is used to verify the validity of the bound signature information and to check the rationality of the timestamp information; If both the validity check and the reasonableness check pass, the first memory card identifier, the first user identifier, and the first device identifier are matched with the second memory card identifier, the second user identifier, and the second device identifier, respectively, to obtain the identifier matching result; Based on the identifier matching result, determine whether the memory card has passed verification.

5. The method according to claim 4, characterized in that, The method further includes: The first storage card identification information, the first user identification information, and the first device identification information are reported to the cloud device for blacklist checking; Based on the identifier matching result, it is determined whether the memory card has passed verification, including: Based on the identifier matching result and the blacklist check result, determine whether the memory card has passed verification.

6. The method according to claim 5, characterized in that, Based on the identifier matching result and the blacklist check result, determine whether the memory card has passed verification, including: If all identifier matching results are correct and the blacklist check results are passed, the memory card verification is confirmed to be successful, and data access to the memory card is permitted.

7. The method according to claim 5, characterized in that, Based on the identifier matching result and the blacklist check result, determine whether the memory card has passed verification, including: If both items in the identifier matching result match correctly and the blacklist check result passes, the memory card verification part is determined to be passed, allowing data access to a portion of the data in the memory card.

8. The method according to claim 7, characterized in that, After confirming that the memory card verification process is successful, the process further includes: Authenticate the currently logged-in user on the terminal device; If authentication is successful, based on the second storage card identifier, the second user identifier, and the second device identifier, the encrypted binding information and data encryption key in the hidden protection partition, as well as the binding information of the cloud device, are updated, and the storage card is confirmed to have been verified.

9. The method according to claim 7, characterized in that, The method further includes: If the number of authentication failures reaches a preset number, it is determined that the memory card authentication has failed, and data access to the memory card is prohibited.

10. The method according to claim 5, characterized in that, Based on the identifier matching result and the blacklist check result, determine whether the memory card has passed verification, including: If fewer than two identifiers match correctly in the matching results, or if the blacklist check fails, the memory card verification is deemed to have failed, and data access to the memory card is prohibited.

11. The method according to claim 9 or 10, characterized in that, After determining that the memory card verification failed, the process also includes: The cloud device is reported to trigger a security warning, so that the cloud device sends a security notification to the user bound to the storage card and generates an anomaly record for this verification. The anomaly record is used to update the blacklist used for blacklist checks. Format the memory card or uninstall the memory card.

12. The method according to claim 11, characterized in that, Formatting the memory card includes: The secure erase algorithm is executed. The first pass writes 0x00 to the entire memory card, the second pass writes 0xFF to the entire memory card, and the third pass writes random data to the entire memory card. Rebuild the partition table of the memory card and create a preset standard file system; Notify the cloud device to clear the corresponding binding information.

13. A data access method for a memory card, characterized in that, The method includes: The method described in any one of claims 4 to 12 is used to determine that the memory card has passed verification; The encrypted data encryption key is decrypted using the second master key, which is read from the hidden protection partition. Use the data encryption key obtained through decryption to perform data access operations.

14. The method according to claim 13, characterized in that, The method further includes: Based on the data access operation, the most recent access time of the storage card is recorded, and the timestamp information in the binding relationship data is updated based on the most recent access time.

15. A terminal device, the device comprising a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein, When the computer program instructions are executed by the processor, the device is triggered to perform the method of any one of claims 1 to 14.

16. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as claimed in any one of claims 1 to 14.

Images