Photograph data protection method and apparatus, electronic device, and computer program product

Abstract

Embodiments of the present application disclose a photographing data protection method and device, electronic equipment and computer program product. The method comprises: obtaining an evidence snapshot generated by this photographing, the evidence snapshot being used for determining the authenticity of the photograph taken this time; performing a key operation trial on a plurality of preset data protection levels in stages by using a preset trial strategy to determine a data protection level adopted by this photographing; determining a multi-layer protection key of the evidence snapshot by using a predefined multi-layer key structure according to the data protection level adopted by this photographing; encrypting the evidence snapshot by using the multi-layer protection key of the evidence snapshot, and outputting structured encrypted evidence data. In a real environment where hardware security capabilities are highly heterogeneous and devices falsely report hardware capabilities, the present application can adaptively determine a data protection level according to the actual available security capability of the device; the multi-layer key structure is used to improve the data protection capability, realize cross-level compatibility, and reduce the operation and maintenance complexity.

Description

Technical Field

[0001] This application relates to the field of anti-counterfeiting and protection technology of image data, and in particular to a method and apparatus, electronic device and computer program product for protecting photographic data. Background Technology

[0002] With the widespread use of mobile devices in scenarios such as electronic forensics, contract preservation, and on-site verification, the evidence data generated by taking photos needs to be effectively protected locally on the device to prevent unauthorized tampering. The ideal protection method is to freeze the evidence snapshot at the moment of shutter release and encrypt the evidence data using a hardware key (a key hosted by an independent security chip or a trusted execution environment).

[0003] However, in real-world environments where hardware security capabilities are highly heterogeneous and some devices may falsely claim capabilities, existing solutions struggle to provide effective and flexible data protection. Summary of the Invention

[0004] This application provides a method and apparatus, electronic device and computer program product for protecting photographic data, in order to improve the effectiveness and flexibility of photographic data protection in a real environment where hardware security capabilities are highly heterogeneous and some devices may falsely claim capabilities.

[0005] This application provides the following solution: According to the first aspect, a method for protecting photographic data is provided, the method comprising: Obtain an evidence snapshot generated during this photo taking, and the evidence snapshot is used to determine the authenticity of the photo taken. By using a preset probing strategy, key operations are performed at each of the preset data protection levels to determine the data protection level adopted for this photo capture. Based on the data protection level adopted in this photo shoot, the multi-layer protection key of the evidence snapshot is determined using a predefined multi-layer key structure; The evidence snapshot is encrypted using a multi-layered protection key to output structured encrypted evidence data.

[0006] According to a second aspect, a device for protecting photographic data is provided, the device comprising: An acquisition unit is used to acquire an evidence snapshot generated during this photo taking, and the evidence snapshot is used to determine the authenticity of the photo taken during this photo taking; The probing unit is used to perform step-by-step key operation probing on multiple preset data protection levels using a preset probing strategy to determine the data protection level adopted for this photo capture. The determining unit is used to determine the multi-layer protection key of the evidence snapshot based on the data protection level of the data acquired in this photo capture, using a predefined multi-layer key structure; An encryption unit is used to encrypt the evidence snapshot using a multi-layered protection key, and output structured encrypted evidence data.

[0007] According to a third aspect, an electronic device is provided, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any one of the first aspects above.

[0008] According to a fourth aspect, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0009] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: This application's embodiments, rather than relying on static capability declarations, adaptively determine the data protection level based on the device's currently available security capabilities by probing the preset multi-level protection levels through runtime key operations during the photo-taking period. This is achieved even in real-world environments with highly heterogeneous hardware security capabilities and the possibility of devices falsely claiming hardware capabilities. Simultaneously, the multi-layered key structure enhances data protection capabilities, and when the protection level is downgraded, only the upper-level key is replaced without changing the ciphertext format, ensuring the consistency of the server-side parsing path. This achieves cross-level compatibility, reduces operational complexity, and allows high-end devices to fully utilize hardware security capabilities while ensuring uninterrupted photo-taking even for low-end devices. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart of a method for protecting photographic data in an embodiment of this application.

[0012] Figure 2 This is a schematic diagram of a key operation probing process in an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of the interaction verification logic between a terminal device and a server in an embodiment of this application.

[0014] Figure 4This is a schematic diagram illustrating the process of constructing a list of falsely reported device capabilities in an embodiment of this application.

[0015] Figure 5 This is a schematic diagram of a two-layer key structure in an embodiment of this application.

[0016] Figure 6 This is a schematic diagram of a field-by-field signature and reporting process in an embodiment of this application.

[0017] Figure 7 This is a schematic diagram of the structure of a device for protecting photographic data in an embodiment of this application.

[0018] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0019] 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, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0020] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0022] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0023] The existing technologies have the following main shortcomings: First, the hardware security capabilities of devices are extremely fragmented. Within the Android device ecosystem, the hardware security capabilities of different devices vary significantly: some devices are equipped with independent security chips (such as StrongBox introduced by Google in Android 9, whose key operations are completely independent of the main processor and not exposed to the main operating system) or Secure Elements (commonly found in bank cards or SIM cards); some devices only provide Trusted Execution Environments (TEEs, secure operating zones that share the processor with the main operating system but are physically isolated, and the main operating system cannot read or write their internal data); some manufacturers provide proprietary secure camera capabilities at the system level; and some devices only have pure software keystores. If the highest level of protection is uniformly required, a large number of devices will be directly unusable; if the lowest level of protection is uniformly applied, the hardware security capabilities of high-end devices will be wasted, and the verification side will be unable to distinguish the actual protection strength of different devices.

[0024] Second, some devices have a problem with misrepresenting hardware capabilities. Some devices' system interfaces claim to support StrongBox (i.e., return a "supported" capability declaration) during queries, but in reality, they lack an independent security unit. They only fail or silently degrade to a TEE when actually invoking key operations. Selecting a protection level solely based on a "support declaration" can lead to runtime crashes or a silent downgrade to a weaker level than expected, without the upper-layer application being aware of this degradation.

[0025] Third, the Key Attestation mechanism has inherent limitations. Key Attestation is a hardware-provided proof mechanism provided by Android to demonstrate that a key was indeed generated within the StrongBox or TEE. However, this proof only guarantees that "a key was once generated within the hardware," not that "the hardware is still usable at the time of the photo capture." Hardware keys may become invalid or be revoked due to system upgrades, changes in security status, user actions, etc. Furthermore, the Attestation chain itself is susceptible to forgery or replay attacks.

[0026] Fourth, downgrading means no protection, and the reason for downgrading is not recorded. When the existing solution encounters hardware unavailability, it either fails completely, making the photo-taking function unusable, or it directly reverts to an unprotected state (i.e., the state most easily exploited by attackers); and it does not record the reason for downgrading, making it impossible for the verification side to know what level of protection the evidence data was under at the time and why it was downgraded to the current level.

[0027] Fifth, security levels are not included in the verification process, and evidentiary data is treated as a binary attribute. Existing solutions simply treat evidentiary data as "either trustworthy or untrustworthy," rather than structured data with a verifiable strength of protection attribute. This forces the verification side to employ only the weakest verification strategy, wasting the higher trustworthiness that could be provided by advanced equipment.

[0028] Sixth, downgrading compromises data format compatibility. If different protection levels use different key structures or ciphertext structures, downgrading will require the verification side and the server to follow different parsing branches according to different levels, resulting in high maintenance costs and a high risk of errors.

[0029] Based on this, this application provides a method for protecting photographic data. Figure 1 This is a flowchart of a method for protecting photographic data according to an embodiment of this application, such as... Figure 1 As shown, the method may include the following steps S110 to S140: Step S110: Obtain an evidence snapshot generated during this photo taking, the evidence snapshot being used to determine the authenticity of the photo taken.

[0030] The data protection method for photographs described in this application can be applied to various terminal devices with photo-taking capabilities and data protection requirements. In step S110, at the shutter trigger moment, the terminal device synchronously reads ground truth data from each acquisition channel. Acquisition channels include, but are not limited to, clock sources, GNSS modules, network positioning modules, and sensor modules. The read data includes current time, latitude and longitude, altitude, speed, and address. Data reading from each channel is completed at the same time point and is atomically frozen all at once, thereby constructing an immutable evidence snapshot and its field-level signature for subsequent determination of the authenticity of the photograph.

[0031] Step S120: Using a preset probing strategy, perform key operation probing at each of the preset data protection levels to determine the data protection level adopted for this photo capture.

[0032] The terminal device has multiple data protection levels pre-set, arranged from strongest to weakest, forming a data protection trust ladder. During the photo-taking period, starting from the strongest level, the device actually initiates an end-to-end key operation probe for the current level. This means generating a temporary key and completing a full encryption / decryption or signature verification loop, rather than simply querying the hardware capability declaration. If the probe is successful, that level is adopted as the data protection level for this photo-taking; if the probe fails, the reason for the failure is recorded, and the device automatically reverts to the next weaker level and re-probes until a level is successfully probed.

[0033] It should be noted that the timing of the above-mentioned probing operation can be set to synchronous (such as probing immediately when the shutter is triggered) or asynchronous (such as warming up when the application starts), and this application embodiment does not limit this.

[0034] Step S130: Based on the data protection level adopted in this photo capture, determine the multi-layer protection key of the evidence snapshot using a predefined multi-layer key structure.

[0035] After determining the data protection level adopted, a predefined multi-layer key structure is used to determine the multi-layer protection key corresponding to the evidence snapshot. In one optional implementation, a two-layer key structure is used. When the protection level is downgraded, only the upper-layer key needs to be replaced; the lower-layer key and the format of the generated ciphertext remain unchanged, thus ensuring that the downgrade process does not damage the data structure. It should be noted that the multi-layer protection key determined in this step is only used to protect the evidence data during local storage on the terminal side, preventing the evidence data from being tampered with without trace or read by other modules in the same process. It does not involve end-to-cloud transmission encryption scenarios.

[0036] Step S140: Encrypt the evidence snapshot using the multi-layer protection key of the evidence snapshot, and output structured encrypted evidence data.

[0037] The evidence snapshot is encrypted using the multi-layered protection key determined in step S130, ultimately outputting structured encrypted evidence data. This encrypted evidence data carries information such as the data protection level of the actual data adopted, and participates in the upper-level verification process as a verifiable attribute.

[0038] This application's embodiments, rather than relying on static capability declarations, adaptively determine the data protection level based on the device's currently available security capabilities by probing the preset multi-level protection levels through runtime key operations during the photo-taking period. This is achieved even in real-world environments with highly heterogeneous hardware security capabilities and the possibility of devices falsely claiming hardware capabilities. Simultaneously, the multi-layered key structure enhances data protection capabilities, and when the protection level is downgraded, only the upper-level key is replaced without changing the ciphertext format, ensuring the consistency of the server-side parsing path. This achieves cross-level compatibility, reduces operational complexity, and allows high-end devices to fully utilize hardware security capabilities while ensuring uninterrupted photo-taking even for low-end devices.

[0039] In some embodiments of this application, the preset multiple data protection levels include the following levels of protection capabilities from strong to weak: independent security chip level, trusted execution environment level, vendor proprietary security camera level, protected software key level, and pure software protection level.

[0040] In some embodiments of this application, the preset multiple data protection levels can be divided into five levels according to their protection capabilities, from strongest to weakest, denoted as L0 to L4, forming a hardware trust ladder. As shown in Table 1: Table 1 Level L0 is the independent security chip level, using independent security chips such as StrongBox or Secure Element as the carrier for key operations. At this level, key generation, storage, and encryption / decryption operations are all completed within the independent chip, achieving physical isolation from the main processor. Furthermore, the independent security chip typically possesses publicly available attestation capabilities, enabling it to provide verified proof of key existence to external parties. Therefore, this level offers the strongest physical isolation and auditability, and is set as the highest protection level.

[0041] Level 1 is the Trusted Execution Environment (TEE) level, which utilizes a TEE as the execution environment for key operations. Although the TEE shares the same system-on-a-chip (SoC) with the main processor, it has a separate execution space at the hardware level. Key operations are completed in this isolated environment, which is inaccessible to the main operating system and ordinary applications. Compared to Level 0, the TEE lacks the physical isolation advantage of a dedicated chip, but it still provides a certain level of hardware-level protection and public certification support.

[0042] Level 2 is a vendor-specific security camera level, where key operations are carried out by a security camera module or security unit provided by the device manufacturer. The specific implementation of this level varies by vendor; some vendor solutions may be equipped with independent security coprocessors or independent microcores, while others rely on dedicated hardware units within the SoC. Since vendor-specific solutions are generally weaker than general-purpose TEEs in terms of public authentication coverage and cross-vendor auditability, they are placed below L1 in the default order. However, embodiments of this application allow adjustment of the relative order of L1 and L2 based on the specific device configuration information. If the actual hardware root of trust of a vendor-specific solution on a device is stronger than that of the general-purpose TEE on that device, then L2 can be placed before L1, as long as the overall hierarchy is maintained from strong to weak and the weakest level is guaranteed to be a safety net.

[0043] Level 3 is a protected software key level, where keys are stored on the terminal side in the form of a software keystore with integrity verification. This level does not rely on a dedicated hardware isolation environment, but prevents keys from being illegally read or tampered with through software-level integrity verification mechanisms. Its protection capability is weaker than the aforementioned hardware-related levels, but it can still provide a certain degree of anti-tampering protection on devices without dedicated hardware support.

[0044] Level 4 is a pure software protection level that uses common software encryption algorithms to protect evidence data without relying on any hardware-level security capabilities. Level 4 is a deterministic executable software path that will inevitably complete an end-to-end loop. Therefore, this level serves as a safety net, ensuring that even on low-end devices without any hardware security capabilities, the photo-taking process will not be interrupted due to the inability to find a usable protection level, thus achieving full device coverage for the photo-taking function.

[0045] The five-tier ranking above is based on a comprehensive consideration of three dimensions: the physical isolation strength of the location where key operations occur, auditability, and public certification coverage. In actual operation, the device probes downwards step by step from L0, and each tier must be verified through actual end-to-end key operations, rather than just checking hardware capability claims, thereby ensuring that the adopted tier is the highest protection level currently available to the device.

[0046] Of course, it should be noted that, in addition to the five protection levels listed above, those skilled in the art can flexibly expand and adjust the protection levels according to the actual situation, and no specific limitations are made here.

[0047] This application's embodiments divide data protection capabilities into a multi-tiered system, ranging from independent security chips to pure software protection. The ranking of each tier is determined by comprehensively considering three dimensions: physical isolation strength, auditability, and public certification coverage. This ensures that terminal devices with different hardware security capabilities can find a protection level that matches their actual capabilities within this tier. Simultaneously, it allows for adaptation and adjustment of the relative order of some tiers based on specific device configurations, balancing the universality of the tiered system with the differences between devices. Combined with a runtime step-by-step probing mechanism, it can accurately identify the true usable level of devices in scenarios where they falsely report hardware capabilities, achieving comprehensive protection for a massive number of heterogeneous devices while allowing each device to utilize its strengths.

[0048] In some embodiments of this application, the step of using a preset probing strategy to perform step-by-step key operation probing on multiple preset data protection levels to determine the data protection level for this photo acquisition includes: performing end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level, wherein the current probing level is one of multiple preset data protection levels; if the key operation probing result of the current probing level is successful, then the current probing level is used as the data protection level for this photo acquisition; if the key operation probing result of the current probing level is unsuccessful, then the probing is downgraded to the next data protection level until the data protection level for this photo acquisition is determined.

[0049] During the photo-taking period, the terminal device, starting from the highest of several preset data protection levels, sequentially selects the current level as the current probe level and performs end-to-end key operation probes on that current probe level. This end-to-end key operation probe refers to actually executing a complete key generation and encryption / decryption loop operation within the hardware or software environment corresponding to the current probe level, rather than merely querying the system for the capability declaration or existence flag of that level. After the probe is completed, the key operation probe result for the current probe level is obtained based on whether the key operation was successfully executed.

[0050] If the key operation test at the current testing level is successful, it indicates that the security capabilities upon which this level relies are actually available on the current device. The testing process then terminates, and this current testing level is directly determined as the data protection level adopted for this photo capture. If the key operation test at the current testing level fails, it indicates that the security capabilities claimed by this level are unavailable or inaccessible on the current device. The device records the reason for the failure and automatically downgrades the testing target to the next weaker level in the preset level sequence. This next level is then used as the new current testing level, and the end-to-end key operation test is re-executed. This downgrade and retry process continues until a testing result at a certain level is successful. This level is then determined as the final data protection level adopted for this photo capture. Since the preset data protection levels include a pure software protection level as the weakest level, this safety net level does not rely on any dedicated hardware security capabilities. Therefore, the testing process will inevitably terminate at a certain level, preventing a situation where all levels fail to be tested.

[0051] This application embodiment verifies each preset data protection level by performing a real end-to-end key operation during the photo-taking process, rather than relying on the hardware capability declarations statically reported by the device. This ensures that the determination process of the protection level strictly corresponds to the actual security capabilities available to the device. It can effectively identify and bypass situations where some devices falsely report hardware security capabilities, and avoid the failure of the photo-taking process or the evidence data being in an unprotected state due to the adoption of a protection level that the device does not actually possess. At the same time, the probing strategy adopts a step-down approach from high to low, ensuring that the highest possible protection level is always adopted within the range allowed by the device's capabilities, maximizing the use of the device's existing security resources. The weakest level of the backup design ensures that the photo-taking function will not be interrupted due to insufficient security capabilities on any terminal.

[0052] In some embodiments of this application, the step of performing end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level includes: querying whether the key service interface of the current probing level exists; if the key service interface of the current probing level exists, generating a probing key for the current probing level in the key backend of the current probing level, and executing a complete encryption / decryption loop or signature verification loop using the probing key of the current probing level; if the encryption / decryption loop or the signature verification loop is executed successfully, the key operation probing result of the current probing level is determined to be a successful probing; if any of the following occurs: the key service interface of the current probing level does not exist, the probing key generation fails, the encryption / decryption loop execution fails, or the signature verification loop execution fails, the key operation probing result of the current probing level is determined to be a failed probing.

[0053] like Figure 2 The diagram illustrates a key operation probing process according to an embodiment of this application. In this embodiment, the end-to-end key operation probing process for the current probing level is divided into three stages: interface availability query, probing key generation, and end-to-end loop execution. These three stages are executed sequentially, and failure in any one stage indicates a failure of the probing level.

[0054] First, the system checks if the required key service interfaces for the current probing level exist. Key service interfaces refer to the set of system key capability interfaces required for the current level; different levels correspond to different interface combinations. Taking levels L0 to L4 as an example, the key service interfaces for level L0 include the system key repository interface, the independent security chip endorsement interface, and the Attestation challenge interface; level L1 corresponds to the system key repository interface and the Attestation challenge interface; level L2 corresponds to the ordinary trusted execution environment path interface of the system key repository; level L3 corresponds to the software backend interface of the system key repository; and level L4 is provided by a software key repository maintained within the application process, independent of system interfaces. The device determines the availability of the required interfaces for the current level by calling the system key repository to obtain an instance and querying system characteristics. If any required interface does not exist, it records "interface not found" and determines that the key operation probing result for the current probing level has failed, then downgrades to the next level and starts probing again.

[0055] If all key service interfaces for the current trial level exist, then proceed to the second stage, where a one-time trial key is actually generated in the hardware or software key domain corresponding to the current level.

[0056] The third stage then proceeds, executing a complete end-to-end loop using the generated trial key. The end-to-end loop has two optional forms: one is a complete encryption / decryption loop, where the trial key is used to encrypt preset test data, then decrypt the ciphertext, verifying the consistency between the decryption result and the original data; the other is a complete signature verification loop, where the trial key is used to sign preset test data, then the signature result is verified to confirm successful verification. If the execution result of either the encryption / decryption loop or the signature verification loop matches expectations, the key operation trial result for the current trial level is considered successful, and this level is adopted as the data protection level for this photo capture. If any failure occurs in the interface query, key generation, or loop execution stage, including but not limited to the absence of the key service interface, failure to generate the trial key, failure to execute the encryption / decryption loop, or failure to execute the signature verification loop, the key operation trial result for the current trial level is considered a failure. The device records the corresponding failure reason and automatically downgrades to the next weaker level, using this next level as the new current trial level, repeating the above three-stage trial process until a certain level is successfully tested.

[0057] This application embodiment performs three real operations sequentially during the photo-taking process: interface availability query, one-time trial key generation, and complete encryption / decryption or signature verification loop. Instead of simply reading the hardware capability declaration statically reported by the device, the adoption of the protection level is based entirely on the device's actual executable key operation capabilities. This effectively identifies and excludes falsely claimed devices that, while claiming to support a certain level, do not actually possess the corresponding hardware or software capabilities. This avoids interruptions in the photo-taking process or evidence data being left unprotected due to the adoption of a non-existent protection level. Simultaneously, the three-stage end-to-end verification mechanism ensures that only levels that pass the checks from interface existence and key generation to loop execution are adopted. This guarantees that the determined data protection level is strictly consistent with the device's actual usable security capabilities. Combined with a step-down strategy from high to low, this ensures that the photo-taking function is not interrupted due to insufficient security capabilities, and that the device always adopts its highest currently available protection level.

[0058] In some embodiments of this application, the step of performing end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level includes: if the current probing level supports key proof, generating a key proof of the probing key of the current probing level at the key backend of the current probing level; if the key proof of the probing key cannot be generated or the proof chain verification of the key proof fails, determining the key operation probing result of the current probing level as a probing failure.

[0059] To prevent attackers from using user-space hooks to make the probing loop consistently "successful" and mislead the system into adopting a higher level, this application embodiment requires that the one-time key used for probing, such as the L0 independent security chip level and the L1 trusted execution environment level mentioned above, be simultaneously certified by the hardware backend for the corresponding level, that is, to issue an authenticated key existence certificate to the outside world.

[0060] Specifically, after the trial key is generated, the edge application initiates a key proof request to the key backend of the current trial level. The hardware backend then generates a corresponding key proof based on the one-time trial key. This proof contains a chain of proofs that verifies the key was indeed generated by the hardware backend of that level and has not been tampered with. The device verifies the chain of proofs of the obtained key proofs. If the chain of proofs is verified, the device, combined with the execution results of the aforementioned encryption / decryption loop or signature verification loop, determines the key operation trial result of the current trial level as successful. If a key proof cannot be generated, or if a key proof is generated but the chain of proofs fails to be verified, then even if the encryption / decryption loop or signature verification loop appears to have executed successfully in user space, the key operation trial result of the current trial level is still determined to be a failure. The corresponding reason for the failure is recorded, and the device is downgraded to the next level for retrial.

[0061] It should be noted that the generated key proof is retained along with the result of the current probe and can be included in the signature range of subsequent evidence data as part of the evidence data authenticity verification. The purpose of this design is to defend against attackers intercepting and tampering with the execution result of the probe loop through user-space hooking techniques, causing it to consistently return success in user space, thereby tricking the system into adopting a protection level higher than the device's actual capabilities. By requiring the hardware backend to provide key proof and verify the proof chain, the credibility of the probe result no longer depends solely on the execution performance of the user-space software loop, but is instead anchored by the hardware backend's key proof, ensuring that even if the probe loop is bypassed in user space, probe results lacking valid key proof will not be accepted.

[0062] This application's embodiments introduce a secondary verification mechanism in the probing process of the protection level that supports key proof. This mechanism involves the hardware backend issuing key proof and verifying the proof chain. The credibility of the probing result depends on both the execution result of the user-space end-to-end loop and the key proof issued by the hardware backend; neither can be omitted. The end-to-end loop is used to exclude situations where the device falsely reports its hardware capabilities, while the key proof is used to anchor and exclude situations where the user-space probing loop is bypassed by hooks. The two mechanisms complement each other, effectively preventing attackers from using software-level interception and tampering methods to make the system mistakenly adopt a protection level higher than the actual capabilities of the device. This ensures that the final determined data protection level is strictly consistent with the actual usable security capabilities of the device, thereby improving the robustness of the entire hierarchical protection scheme in adversarial environments.

[0063] In some embodiments of this application, the step of performing end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level includes: if the current probing level supports key proof, generating a key proof of the probing key of the current probing level in the key backend of the current probing level, and writing the one-time challenge parameter issued by the server into the challenge parameter field of the key proof; sending the key proof of the probing key of the current probing level and the one-time challenge parameter to the server, so that the server performs anti-replay verification based on the one-time challenge parameter to obtain an anti-replay verification result; if the anti-replay verification result is successful, then the key operation probing result of the current probing level is adopted; if the anti-replay verification result is unsuccessful, then the key operation probing result of the current probing level is not adopted, and the probing is downgraded to the next data protection level.

[0064] For protection levels that support key proof, a replay protection mechanism is further introduced during the end-to-end key operation probing process, using a server-side one-time challenge parameter (nonce).

[0065] Specifically, before the photo-taking process begins, the server generates a one-time challenge parameter using a cryptographically secure random number generator. This one-time challenge parameter is derived from the dynamic signature key held by the server, for example, by performing a digest operation on the dynamic signature key. The server sends this one-time challenge parameter to the terminal via an end-to-cloud encrypted channel, while simultaneously recording the validity period and single-use constraints of the one-time challenge parameter on the server side. When the terminal generates a one-time trial key at the current trial level's key backend, it writes the received one-time challenge parameter as the challenge parameter for the key proof into the challenge parameter field of the key proof, ensuring that this parameter is immutably fixed in the key proof by the hardware backend. Subsequently, the terminal sends the generated key proof and the one-time challenge parameter used in this session to the server.

[0066] After receiving the above information, the server performs a replay protection check. The server maintains a dynamic key consumption table, which records the identifier of each issued dynamic signature key, its corresponding one-time challenge parameter value, issuance time, validity period, bound session or device identifier, and consumption status. During verification, the server first checks whether the one-time challenge parameter carried in the challenge parameter field of the key proof is strictly consistent with the derived value recorded in the current session. It then uses atomic operations to reverse the consumption status of the corresponding entry from unconsumed to consumed, ensuring that the one-time challenge parameter is consumed only once. If the one-time challenge parameter matches and the consumption status is unconsumed, the replay protection check passes, and the server adopts the key operation probe result of the current probe level. If the one-time challenge parameter does not match, or the one-time challenge parameter has been consumed or has expired, the replay protection check fails, the server does not adopt the probe result of the current probe level, and the terminal downgrades to the next data protection level and re-executes the probe. In addition, the server can use the dynamic signature key it holds to verify the server factor signature sent by the terminal, and combine it with the hardware proof signature sent by the terminal to form an edge-cloud two-factor signature. The one-time challenge parameter serves the dual purpose of preventing replay and the cloud factor in the edge-cloud two-factor signature.

[0067] This application's embodiments introduce a replay protection mechanism using a one-time challenge parameter from the server in the protection level probe that supports key proof. This ensures that the key proof generated on the terminal side contains unpredictable parameters specific to the server for that particular session. The server determines whether the probe result is a real-time valid operation by verifying the matching of these parameters and the consumption status. This effectively prevents attackers from intercepting and replaying historical key proofs to fraudulently obtain high-level protection. Simultaneously, the one-time challenge parameter is derived from the server's dynamic signature key and assumes the role of the cloud factor in the end-to-cloud two-factor signature. This allows the replay protection verification and end-to-cloud collaborative signature to be completed synchronously in a single interaction. This not only ensures the timeliness and uniqueness of the probe result but also provides a unified cryptographic foundation for the end-to-cloud two-factor trusted verification of evidence data, further enhancing the security strength of the entire hierarchical protection scheme in adversarial environments.

[0068] In some embodiments of this application, the proof chain of the key proof for the current probing level carries an application binding field. The process of performing end-to-end key operation probing on the current probing level to obtain the key operation probing result includes: extracting the application binding field from the proof chain of the key proof for the current probing level; comparing the extracted application binding field with the application information actually running during the current photo capture; if the extracted application binding field matches the application information actually running during the current photo capture, then the key operation probing result for the current probing level is adopted; otherwise, the key operation probing result for the current probing level is not adopted, and the process is downgraded to the next data protection level for key operation probing.

[0069] In this embodiment of the application, for the protection level that supports key proof, during the end-to-end key operation probing process, the proof chain of key proof is further subjected to application binding verification.

[0070] Specifically, the key proof chain carries an application binding field, which corresponds to the `attestationApplicationId` extension in the Android platform's key proof mechanism. This field is written by the hardware backend along with the package name of the currently calling application and the fingerprint information of the application's signature certificate when issuing the proof. This writing action occurs internally within the hardware backend, and the application process has no right to interfere with or tamper with it. After obtaining the key proof, the terminal parses and extracts the application binding field from the proof chain, obtaining a tuple containing the package name and signature fingerprint set. This tuple is then compared with the package name and signature fingerprint corresponding to the application actually running during the photo capture. If they match completely, it indicates that the key proof was indeed generated by the target application in the current session, and the current level of key operation test result is adopted. If the comparison is inconsistent, it indicates that the key proof may have been obtained and misused by other applications, and the current level of test result is not adopted. The terminal records the corresponding reason and downgrades to the next weaker level to re-execute the test.

[0071] Meanwhile, upon receiving the key proof from the terminal, the server independently performs two verifications. The first is a certificate chain integrity verification, which verifies whether the root certificate belongs to a publicly trusted set of hardware proof root certificates, whether the certificate chain is complete, whether each certificate signature is valid and not expired, and whether each certificate exists on a publicly revoked list. The second is an application binding field verification, which extracts the application binding field from the certificate chain and checks whether the package name matches the allowed application list maintained by the server, and whether the signature fingerprint set is completely consistent with the signature fingerprint configured for this application on the server. If either verification fails, the photo capture is deemed a risk control event, and the corresponding device is added to the risk control device list. This risk control list has an expiration date and supports a manual appeal path to avoid false positives. Subsequent photo capture requests from devices on the list can be handled with differentiated measures on the policy side, such as entering a suspicious queue, mandatory secondary verification, or suspending highly sensitive business functions.

[0072] This application embodiment embeds an application binding field, which is immutably written by the hardware backend, into the proof chain of the key proof. Application identity comparison is performed on both the terminal and server sides, ensuring that the credibility of the key proof is anchored to both "proving it belongs to this session" and "proving it belongs to this application." The one-time challenge parameter ensures the timeliness and prevents replay attacks, while the application binding field ensures the uniqueness of the proof's ownership. These two complementary features eliminate the possibility of attacks such as forgery, replay, or cross-application impersonation of the proof chain. Combined with independent certificate chain integrity verification and application binding verification on the server side, as well as a risk control device list mechanism, this achieves automatic identification and tiered handling of abnormal photo-taking behavior without increasing the user's operational burden. This further enhances the security and credibility of the tiered protection scheme in multi-application coexistence and adversarial environments.

[0073] For ease of understanding of the above embodiments, as Figure 3 The diagram illustrates an interaction verification logic between a terminal device and a server in an embodiment of this application. This flowchart demonstrates the end-to-cloud collaborative interaction process between the user, the terminal side (terminal application + hardware backend), and the server to achieve "anti-replay, anti-impersonation, and tiered risk control" during the graded hardware trust protection of photographic evidence. The specific implementation steps are as follows: (1) Photo session triggering and server nonce issuance When a user presses the shutter button to take a photo, the client application immediately initiates a photo session and sends a one-time challenge parameter (nonce) request to the server. Upon receiving the request, the server generates a one-time nonce using a cryptographically secure random number generator and registers the nonce's validity period and single-use constraints (such as binding a session identifier and setting the initial state to "unconsumed") in the server's dynamic key consumption table. The server then sends the nonce to the client application via a secure channel.

[0074] (2) The hardware backend generates the test key and issues the key proof. Upon receiving the nonce, the client application initiates a key generation request to the device's hardware backend (such as a standalone security chip or trusted execution environment), passing the nonce as a challenge parameter (i.e., challenge=nonce). The hardware backend generates a one-time trial key within its physically isolated security domain and issues a hardware key certificate (Attestation certificate chain) for this key. When issuing the certificate, the hardware backend immutably writes the passed nonce into the challenge field of the certificate chain. After completion, the hardware backend returns the one-time trial key and the complete certificate chain to the client application.

[0075] (3) End-side application binding verification and degradation decision After receiving the certificate chain, the client application performs application binding verification locally. The client application parses the application binding fields (such as the application package name and application signature certificate fingerprint) carried in the key proof from the certificate chain, and compares the parsed application information with the package name and signature fingerprint of the application that is currently running.

[0076] If the comparison is inconsistent, it indicates that the key certificate may have been misused or tampered with by other applications. The client application determines that the current level test has failed, does not adopt the current protection level, and triggers the graceful downgrade process with the reason, automatically downgrading to the next weaker level and re-executing step (2). If the comparison is consistent, it indicates that the key certificate belongs to this application, and the subsequent server-side verification continues.

[0077] (4) Evidence data and the chain of proof The client application uploads the complete data packet to the server. This data packet includes at least: the certificate chain issued by the hardware backend, the nonce used in this session, and evidence snapshots.

[0078] (5) Server-side comprehensive verification and risk control measures After receiving the data packet uploaded by the client, the server independently performs a triple verification: 1) Certificate chain integrity verification: Verify whether the root certificate of the certificate chain is trustworthy, whether the chain is complete and not expired, and whether any node certificate is on the server's public revocation list.

[0079] 2) Nonce Verification (Anti-Replay): Verify that the nonce extracted from the certificate chain challenge field is strictly equal to the nonce issued and recorded in this session; simultaneously check the consumption status of the nonce in the dynamic key consumption table. If the status is "consumed" or has expired, it is determined to be a replay attack. After the verification passes, the nonce status is atomically flipped to "consumed".

[0080] 3) Application binding verification (anti-impersonation): Extract the application binding field from the certificate chain and verify whether the application package name and signature fingerprint completely match the allowed whitelist configured on the server.

[0081] If any of the above three verification steps fail, the server will determine that the current device or current session has a security risk (such as being subjected to a replay attack, certificate forgery, or cross-application impersonation), and will add the corresponding device identifier to the risk control device list.

[0082] (6) Risk control list hit and differentiated follow-up handling For devices or data that are flagged as being on the risk control list, the server implements differentiated handling strategies in subsequent business processes. These strategies include: forcibly transferring the uploaded evidence data to a suspicious queue for manual or in-depth analysis; forcibly triggering secondary verification for the device or user; and directly suspending the device's highly sensitive business functions. This ensures business continuity while effectively blocking potential security threats.

[0083] In some embodiments of this application, the step of using a preset probing strategy to perform step-by-step key operation probing on multiple preset data protection levels to determine the data protection level for this photo capture includes: if the key operation probing result of the current probing level is a failure, generating a probing failure semantic event based on the reason for the failure and reporting it, and downgrading to the next data protection level for key operation probing; wherein, the reason for the failure is any one of the following: interface does not exist, device capability is falsely reported, key is revoked, user authentication is revoked, device enters an abnormal security state, probing operation times out, and other probing operation failure situations.

[0084] In this embodiment of the application, when the key operation attempt at the current attempt level fails, a failure event with corresponding semantics is generated and reported according to the type of failure reason. Then, it is automatically downgraded to the next weaker level in the preset level sequence, and the end-to-end key operation attempt is re-executed with the next level as the new current attempt level.

[0085] The reasons for the aforementioned failed attempts are categorized into several semantic types, including interface non-existence, false device capability reporting, key revocation, user authentication revocation, device entering an abnormal security state, operation timeout, and other failed attempt scenarios. Interface non-existence and false device capability reporting can be identified primarily during the interface availability query or key generation phases. For example, if a device claims to support an independent security chip but throws a hardware unavailable exception during actual invocation, it is determined to be a false capability report. This semantic difference from a general interface non-existence indicates that the device is falsely reporting hardware capabilities. Key revocation, user authentication revocation, and device entering an abnormal security state can be seen as key invalidation scenarios, triggered during the key generation phase or the end-to-end loop key usage phase. Specifically, they are categorized according to the location of the underlying exception: key revocation corresponds to the key being actively marked as permanently invalid by the system; user authentication revocation corresponds to the user actively revoking the device authentication required for fingerprint, facial recognition, or lock screen credentials; and device entering an abnormal security state corresponds to situations such as the device being in the unlock bootloader phase, obtaining root privileges, verification startup failure, or abnormal security enhancement mechanism. Operation timeout refers to the situation where the overall attempt exceeds a preset time limit. Other failed trial operations are used as a catch-all clause, referring to general failures other than those mentioned above.

[0086] It should be noted that the core difference between "interface not existing" and "device capability misrepresentation" lies in whether the device has ever declared support for that level of capability, specifically in the following two aspects: First, the stages at which failures occur differ. "Interface not found" can be identified during the interface availability query phase; that is, when the terminal checks whether the key service interface required for the current probe level exists, it finds that the interface is completely unavailable in the system, and the probe terminates before key generation. "False device capability claims," ​​on the other hand, occur during the key generation phase or the end-to-end loopback phase. At this point, the interface availability query has passed, but the device's lack of the claimed hardware capabilities for that level is only revealed when the probe key is actually generated or the encryption / decryption loop is executed.

[0087] Second, the semantic meanings are different. "Interface does not exist" indicates that the device does not provide the necessary capabilities for this level of protection at the system level, meaning the device genuinely lacks the hardware foundation for that level of protection. "Device capability false reporting," on the other hand, indicates that the device claims to support this level of protection at the system level (the interface does exist), but during actual end-to-end key operations, it reveals that it does not possess the corresponding hardware root of trust, representing a situation where the device claims to support it but it is actually unusable. Therefore, in this embodiment, "device capability false reporting" is specifically distinguished as a semantic independent of general failure, to accurately identify the specific scenario of "system claims support but end-to-end probe fails," enabling the risk control side to identify the behavior of the device falsely reporting hardware capabilities, rather than confusing it with ordinary interface absence.

[0088] During the trial process, the reasons for each trial failure are recorded in a structured enumeration field rather than free text. These enumeration fields may include values ​​such as interface non-existence, trial operation failure, operation timeout, false capability reporting, key revocation, user authentication withdrawal, and device entering an abnormal security state. Since the preset data protection levels include a pure software protection level as the weakest safety net, which does not rely on any dedicated hardware security capabilities, the downgrade trial process will inevitably terminate successfully at a certain level, and the photo-taking function will not be interrupted due to insufficient security capabilities. The reasons for each trial failure and the final adopted protection level are all stored along with the evidence data, allowing the server to execute differentiated risk control strategies accordingly.

[0089] It should be noted that the enumeration values ​​for the reasons for the failure of the above-mentioned attempts can be flexibly trimmed and expanded according to the actual situation, and will not be listed one by one here.

[0090] This application embodiment subdivides the reasons for trial failures semantically and records them with structured enumeration fields and stores them along with evidence data. This ensures that each downgrade carries clear failure semantic information. The server can then take differentiated risk control measures for devices that falsely claim capabilities, devices with invalid keys, and devices in abnormal security states, rather than treating them all the same. At the same time, distinguishing false capability claims as an independent semantic from general failures can accurately identify the behavior of devices falsely claiming hardware capabilities. Combined with the graceful downgrade mechanism, this ensures that the photo-taking function is not interrupted on any terminal, achieving a balance between security protection and business continuity.

[0091] In some embodiments of this application, the method further includes: caching the key operation probing results of each probing level using a preset caching strategy; the step of using the preset probing strategy to perform step-by-step key operation probing on multiple preset data protection levels to determine the data protection level for this photo taking includes: searching in the cached key operation probing results according to the current probing level; if the key operation probing result of the current probing level is found in the cached key operation probing results, then the cached key operation probing result is used directly; otherwise, end-to-end key operation probing is performed on the current probing level to obtain the key operation probing result of the current probing level.

[0092] In this embodiment of the application, the terminal device has a preset probe caching strategy to manage the caching of key operation probe results at each probe level, so as to avoid repeatedly executing high-overhead end-to-end key operation probes when the device state has not changed.

[0093] Specifically, the key operation results obtained from each attempt are associated with the current device's identity and system status information and then cached. The cached composite key can be composed of device model, system version, security patch level, verification startup status, mandatory access control status, device root status, and bootloader unlock status, etc. Any change in any of the above status information will trigger cache invalidation. The cache validity period can be configured to a number of days, for example, it can be set to expire before the next system upgrade takes effect, or it can expire immediately when any of the above statuses change.

[0094] When a terminal device needs to determine the data protection level for a photo taken during the photo-taking period, it can first search the cached key operation test results based on the current test level. If a valid cached result is found for the current test level, that cached result is directly used as the key operation test result for the current test level, without needing to re-execute the end-to-end key operation test. If no valid cached result is found, the end-to-end key operation test is actually performed for the current test level to obtain a new test result and update the cache.

[0095] It should be noted that the embodiments of this application also support a mode in which the caching strategy is not enabled, that is, a full step-by-step trial is re-executed every time a photo is taken. This mode also falls within the protection scope of this application. The specific mode adopted is determined by the preset strategy.

[0096] This application's embodiments introduce a composite keyword caching mechanism based on device identity and multi-dimensional system status. This allows for the direct reuse of existing trial results in continuous photo-taking scenarios where the device's hardware capabilities and security status remain unchanged, without the need to repeatedly perform costly end-to-end key operations. This effectively reduces latency and resource consumption in the photo-taking process. Simultaneously, the cache expiration condition is bound to security-related dimensions such as verification startup status and mandatory access control status. This ensures that a change in the device's security status triggers cache expiration and forces a re-trial, avoiding the adoption of protection levels that are incompatible with the device's current security capabilities due to cache expiration. This balances operational efficiency and security accuracy.

[0097] In some embodiments of this application, the method further includes: when the failure of the current probing level is due to false reporting of device capabilities, signing the current probing level and device identification information; reporting the current probing level, the device identification information, and the corresponding signature to the server so that the server can construct or update the list of falsely reported device capabilities; the step of using a preset probing strategy to perform step-by-step key operation probing on multiple preset data protection levels to determine the data protection level for this photo taking includes: obtaining the list of falsely reported device capabilities; searching the list of falsely reported device capabilities based on the device identification information of the current probing level; if the device identification information of the current probing level can be found in the list of falsely reported device capabilities, then directly downgrading to the next data protection level for key operation probing; otherwise, performing end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level.

[0098] like Figure 4 The diagram illustrates a process for constructing a list of falsely reported device capabilities, as shown in this embodiment. In this embodiment, when the failure reason for the current probe level is determined to be false reporting of device capabilities, the identifier of the current probe level and the device identifier information are signed. The signed current probe level information, device identifier information, and corresponding signature are then reported to the server, which constructs or updates the list of falsely reported device capabilities accordingly. The reported data itself is signed on the client side and includes evidence of the failure of this end-to-end probe, including an enumeration of failure reasons and a key proof for the next lower level if a key proof is available, to ensure the credibility of the reporting source.

[0099] Upon receiving a report, the server aggregates and filters the reported data based on two thresholds: a model-level anomaly rate threshold and a maximum percentage limit for a single reporting source. Specifically, using the most recent T days as a time window, the server calculates the proportion of reports locally identified as false alarms for a particular model and level combination relative to the total number of trial reports for the same model and level. If this proportion is not lower than the model-level anomaly rate threshold, the server further checks whether the proportion of false alarm reports for that model and level combination from the same reporting source within that window does not exceed the maximum percentage limit for a single reporting source. Only when both conditions are met is the model and level combination included in the list of false equipment capability reports. Once the list is built, it is distributed to the terminal.

[0100] In the subsequent photo-taking process, when determining the data protection level for this photo-taking using a preset probing strategy, the terminal can first obtain a list of devices with false capability claims and then search this list based on the current probing level and device identification information. If the combination of the current probing level and device identification information is found in the list, it indicates that the device has been independently verified by multiple parties as having false capability claims at that level. The terminal device will then skip this level and downgrade to the next data protection level to re-perform the key operation probing. If no such case is found, the end-to-end key operation probing will proceed normally at the current probing level.

[0101] This application embodiment uses a server-side-built and maintained list of false device capabilities to allow subsequent devices of the same model to skip levels that have been independently verified as false by multiple parties, avoiding repeated and ineffective attempts that waste resources. At the same time, the dual threshold mechanism requires that the false report determination be obtained consistently and stably by multiple independent reporting sources within a certain time window, effectively defending against poisoning attacks that cause a certain model to be incorrectly downgraded by forging a large number of reports of the same model. This improves the efficiency of the attempts while ensuring the accuracy and resistance to attacks of the list.

[0102] In some embodiments of this application, the predefined multi-layer key structure is a two-layer key structure, which includes an upper-layer key encryption key and a lower-layer data encryption key. Both the key encryption key and the data encryption key are generated and managed in the backend of the key for the data protection level of the data captured in this photo. The key encryption key is used to encrypt the data encryption key into a packaged data encryption key, and the data encryption key is used to encrypt the evidence snapshot into evidence snapshot ciphertext.

[0103] like Figure 5The diagram illustrates a two-layer key structure according to an embodiment of this application. In this embodiment, the predefined multi-layer key structure employs a two-layer architecture, including an upper-layer key encryption key (KEK) and a lower-layer data encryption key (DEK). Both KEK and DEK are generated and managed within the key backend corresponding to the data protection level adopted in this photo capture, and all key operations are completed within this key backend; user-space code does not access any plaintext keys.

[0104] The Key Encryption Key (KEK) is generated internally by the hardware backend corresponding to the current adoption level. The key material remains within the hardware backend boundary throughout its generation and destruction. Different protection levels correspond to different hardware backends; therefore, the physical location and attributes of the KEK change with the adoption level. The Decryption Key (DEK) is generated internally by a cryptographically secure random source built into the hardware backend. It is a unique random symmetric key used for this particular photo capture, with one key generated for each capture. After generation, the DEK is immediately encapsulated internally by the KEK for the current adoption level within the hardware backend, encrypting it into a packaged data encryption key. This packaged DEK is stored along with the encrypted evidence snapshot. The encryption of the evidence snapshot is performed using the data encryption key, while decryption requires the KEK to first decapsulate the DEK internally within the hardware backend, and then the decapsulated DEK performs the decryption.

[0105] When the probing process is downgraded, the hosting provider of the KEK is changed to the hardware backend corresponding to the next level, but the data format of the DEK and its encapsulated state, as well as the encrypted evidence snapshot, remains unchanged, and the server-side parsing path remains consistent.

[0106] It should be noted that only one protection level is adopted in a single photo capture process. This level is frozen after the trial phase is completed. All key operations in this photo capture process use the KEK corresponding to this level, and switching levels midway is not allowed. If the adopted level becomes invalid during the photo capture process due to reasons such as key revocation, abnormal trusted execution environment session, or device entering a security abnormal state, the entire photo capture process is invalidated and reported as an independent event, rather than switching to a lower level and regenerating ciphertext midway, thus avoiding the situation where multiple levels of ciphertext coexist in the same photo capture process.

[0107] This application's embodiments employ a two-layer structure of key encryption and data encryption keys, and constrain the generation, encapsulation, and encryption / decryption operations of both keys to be executed within the hardware backend corresponding to the adoption level. This ensures the confidentiality and integrity of evidence data during storage by a hardware-level key system, preventing user-space processes from obtaining any plaintext keys. Simultaneously, during downgrades, only the custodian of the key encryption key is changed while maintaining the data encryption key and ciphertext format, ensuring the consistency of the server-side parsing path. Furthermore, the design of freezing the adoption level within a single photo capture avoids the problems of increased attack surface and strategy complexity caused by the coexistence of multiple levels of ciphertext.

[0108] In some embodiments of this application, determining the multi-layer protection key of the evidence snapshot using a predefined multi-layer key structure based on the data protection level of the current photo capture includes: using the probe key corresponding to the data protection level of the current photo capture as the key encryption key; and generating the data encryption key using a random symmetric key generation algorithm on the back end of the key for the data protection level of the current photo capture.

[0109] As in the aforementioned embodiments, the multi-layered protection key of the evidence snapshot can consist of two layers: a key encryption key and a data encryption key. The generation and management of both layers of keys are completed within the hardware backend corresponding to the data protection level of this photo capture.

[0110] The process of determining the encryption key is integrated with the probing process. A candidate encryption key is generated once within the key backend at the current probing level. This candidate encryption key is the one-time probing key generated during the aforementioned end-to-end key operation probing. This candidate encryption key is used to execute an encryption / decryption loop or a signature verification loop, and the hardware backend issues a key certificate corresponding to this level. Once the loop execution, key certificate, and application binding verification all pass, the candidate encryption key is adopted as the final encryption key for this photo capture, and it does not need to be generated again during the entire photo capture cycle. In other words, the one-time probing key used during the probing process is directly converted into the official encryption key used for protection after passing all verifications, and the probing and key adoption are completed continuously within the same session on the same hardware backend.

[0111] After the adoption level is frozen, a random symmetric key is generated internally by a cryptographically secure random source built into the hardware backend corresponding to that adoption level using a symmetric encryption algorithm (AEAD). This random symmetric key is stored internally in the hardware backend from the moment it is generated and does not pass through user space. The symmetric encryption algorithm provides both encryption and integrity verification, also known as authenticated encryption. Those skilled in the art can replace it with other similar algorithms according to actual needs.

[0112] The adopted key encryption key is then used internally in the hardware backend to encapsulate the random symmetric key, generating an encapsulated data encryption key. This encapsulated data encryption key is output to the user space, where it is used internally in the hardware backend to encrypt the evidence snapshot, yielding the ciphertext of the evidence snapshot. All key operations—encapsulation, encryption, decryption, signing, and verification—are performed internally in the adopted-level hardware backend. The user space only sends data to be operated on via a request interface and receives the operation results, without accessing any plaintext keys. A new data encryption key is generated for each snapshot and is not reused across snapshots.

[0113] This application embodiment directly converts the one-time key generated during the probing phase into the encryption key for this photo capture after passing all verifications. This allows the probing and key adoption to be completed in one go within the same hardware backend session, avoiding wear and contamination of the official key by the probing operation. At the same time, the generation of the data encryption key is strictly constrained to be completed internally by the hardware backend's built-in random source after the adoption level is frozen. This ensures that the entire chain from key generation and encapsulation to data encryption does not pass through user space. The user space process never touches any plaintext key, effectively protecting the confidentiality and integrity of the evidence snapshot during its storage from threats of user space software attacks.

[0114] In an optional embodiment, the key used in the probing phase and the final adopted encryption key can be generated separately. That is, the probing key is not directly used as the official protection key for this photo capture, but is generated independently as a one-time candidate key. The terminal device generates a one-time probing key internally within the key backend of the current probing level. This probing key is only used to perform end-to-end key operation probing, including encryption / decryption loops, signature verification loops, and key proofs corresponding to this level issued by the hardware backend. When the loop execution is successful, and the key proof and application binding verification are all successful, this one-time probing key is not directly adopted as the official encryption key, but rather serves as a candidate key to trigger the generation of the official encryption key. The official encryption key is regenerated by the hardware backend within the same session on the same hardware backend. Immediately after generation, the operation of encapsulating the data encryption key and encrypting the evidence snapshot are performed. Thus, the use of the one-time probing key during the probing phase does not consume or pollute the state of the official encryption key; the official encryption key is in a clean state untouched by probing operations from the time of its generation.

[0115] It's important to note that the probing operation and the initial formal key operation are completed consecutively within the same session on the same hardware backend, sharing the hardware state context of that session. If a hardware state change occurs within this session, including but not limited to situations such as the application switching to the background causing the trusted execution environment session to be reclaimed, user authentication being revoked, or changes in device security status, the adoption is considered invalid, the generated formal key encryption key is not adopted, and the entire probing and adoption process must be retried, rather than using the previous adoption result. This mechanism ensures that the generation of the formal key encryption key is always bound to a complete and uninterrupted hardware session, avoiding damage to the trustworthiness of the formal key due to inconsistent session states.

[0116] In some embodiments of this application, encrypting the evidence snapshot using the multi-layer protection key of the evidence snapshot and outputting structured encrypted evidence data includes: encrypting the evidence snapshot using the data encryption key to obtain ciphertext of the evidence snapshot; encapsulating the data encryption key using the key encryption key to obtain an encapsulated data encryption key; performing field-by-field signatures on the ciphertext of the evidence snapshot, the encapsulated data encryption key, the data protection level adopted in this photo, and the reason for downgrading, to obtain an extended field-level signature of the evidence snapshot; and using the ciphertext of the evidence snapshot, the encapsulated data encryption key, the data protection level adopted in this photo, the reason for downgrading, and the extended field-level signature of the evidence snapshot as the structured encrypted evidence data.

[0117] In this embodiment of the application, after encrypting the evidence snapshot using the determined multi-layer protection key, structured encrypted evidence data is output. This structured data consists of the evidence snapshot ciphertext, the data encryption key in the encapsulated state, the data protection level adopted in this photo, the reason for downgrading, the key proof attached to the level supporting the key proof, and the extended field-level signature of the evidence snapshot.

[0118] The evidence snapshot ciphertext is obtained by performing encryption operations on the evidence snapshot internally on the hardware backend using the data encryption key. The encapsulated data encryption key is obtained by performing encapsulation operations on the data encryption key internally on the hardware backend using the key encryption key. This encapsulated data encryption key can only be decapsulated when the key encryption key is available. The data protection level adopted in this photo capture is the level identifier finally determined in the probing process, and its value range is one of several preset protection levels. The reasons for downgrading are recorded in the form of an enumeration field. This enumeration field includes at least no downgrading, interface not existing, probing operation failed, operation timeout, capability false reporting, key revocation, user authentication revocation, and device entering an abnormal security state. Among them, capability false reporting is used to identify the situation where the system claims to support it but the end-to-end probing fails. Key revocation, user authentication revocation, and device entering an abnormal security state are further subdivisions of key invalidation.

[0119] like Figure 6 The diagram illustrates a field-by-field signing and reporting process in this embodiment. In the signing stage, the terminal device generates a signature for each field independently, rather than merging all fields into a single signature block. Specifically, the ciphertext of the evidence snapshot, the data encryption key in the encapsulated state, the adoption level, the downgrade reason, and the key proof attached to the level supporting key proof are each treated as independent signature objects, generating corresponding signature values. All signature values ​​together constitute the extended field-level signature of the evidence snapshot. The adoption level and downgrade reason, as extended fields of the basic evidence snapshot, are bound to the snapshot and participate in independent field-by-field signing. Tampering with any field will cause the corresponding signature verification to fail. Finally, the ciphertext of the evidence snapshot, the data encryption key in the encapsulated state, the adoption level, the downgrade reason, and the extended field-level signature are assembled into structured encrypted evidence data, which is sent to the server along with the photo-taking business process. The server can then execute differentiated risk control strategies, such as skipping verification for L0 levels, performing secondary verification for L1-L3 levels, and forcing L4 levels into the suspicious queue.

[0120] Of course, those skilled in the art can flexibly adjust which fields to sign according to actual needs, and no specific limitations are made here.

[0121] This application embodiment uses fields such as adoption level, downgrade reason, and key proof as extended fields of the evidence snapshot, each participating independently in field-by-field signing. All fields and signatures are then assembled into structured encrypted evidence data. This expands the credibility verification of the evidence data from a single ciphertext integrity check to a multi-dimensional independent check of the protection level, downgrade reason, and the source of each field. The server can accurately determine the hardware protection strength of the evidence data and implement differentiated risk control strategies according to the level. At the same time, the form of independent field-by-field signing retains the defense capability against attacks that replace the entire legitimate snapshot. Any tampering with a single field will destroy the corresponding signature, thus upgrading the security trust assessment from binary trust to hierarchical trust.

[0122] In some embodiments of this application, the predefined multi-layered data protection levels and their corresponding key backends are not limited to a single operating system platform. Any platform with an equivalent layered hardware root of trust can be used. Each protection level is adapted to the platform's unique hardware security backend through a preset mapping relationship.

[0123] Specifically, on the Android platform, each protection level is mapped to hardware security modules such as StrongBox, TEE with key proof, ordinary TEE, and software backends. On the iOS platform, the highest protection level is mapped to SecureEnclave, a security coprocessor independent of the main processor on Apple devices, and the second highest level is mapped to the keychain hardware backend provided by the iOS system. On the HarmonyOS platform, the two highest protection levels are mapped to the device's corresponding iTrustee or TEE OS. On desktop platforms, the two highest protection levels can be mapped to TPM or fTPM. These mapping relationships are configured by a preset policy. When a terminal device executes the probing process, it loads the corresponding level-backend mapping table according to the current operating platform and sequentially performs key operation probing in the hardware backends indicated by the mapping table. For platforms that do not support key proof mechanisms, the credibility verification of their highest protection level is replaced by a verifiable statement from an equivalent hardware backend of that platform. For example, a credibility statement issued by the platform's own hardware security module can be used to complete a credibility verification equivalent to key proof. The weakest protection level on each platform is guaranteed by a pure software backend, ensuring that the camera function is not interrupted due to insufficient hardware capabilities on any terminal.

[0124] This application embodiment establishes a preset mapping relationship between multi-layered data protection levels and the hardware root of trust unique to each platform, so that the hierarchical key protection scheme is not dependent on a specific operating system and can be uniformly implemented in multiple terminal environments such as Android, iOS, HarmonyOS and desktop platforms. At the same time, the weakest software protection level is used as a business safety net to ensure the functional integrity and business continuity of the scheme when deployed across platforms.

[0125] In some embodiments of this application, the flow of structured encrypted evidence data obtained in the foregoing embodiments is divided into two stages: Phase 1 - Before Upload from the Client Side: Decryption within the Hardware Backend, Plaintext Upload at the Application Layer After the photo is taken, the terminal device needs to convert the encrypted evidence data stored on the server into a format that can be uploaded to the server. The essence of this conversion is to "decrypt two layers of keys and restore the plaintext of the evidence", but the entire decryption process is strictly controlled within the hardware backend, and the user space does not participate in any key calculations.

[0126] Specifically, the user space sends the encrypted evidence snapshot along with the data encryption key from the encapsulation state to the hardware backend via a "decryption request" interface. The hardware backend first uses the key-to-encrypt-key method to decrypt the data encryption key, obtaining the plaintext data encryption key; then, it uses this data encryption key to decrypt the encrypted evidence snapshot, obtaining the plaintext evidence data. After the plaintext evidence data is returned from the hardware backend to the user space, the user space assembles it with the adoption level, downgrade reason, and all signatures according to a predetermined format and sends it to the server via HTTPS / TLS.

[0127] It should be noted that the plaintext of the data encryption key is generated within the hardware backend and destroyed at the end of this photo capture process, never leaving the hardware backend boundary. During the upload process, the user space briefly holds the plaintext evidence data itself for assembling the upload packet, but does not hold or access any plaintext key.

[0128] This leads to the question of the positioning of the two-layer key structure. The design goal of these two layers—the key encryption key and the data encryption key—is to provide end-to-end local protection, preventing evidence data from being tampered with or illegally read by other modules in the same process during device storage. They do not assume responsibility for end-to-cloud transmission encryption. End-to-cloud confidentiality is guaranteed by the transport layer TLS, and end-to-cloud authenticity is guaranteed by three mechanisms: independent field-by-field signature, key verification issued by the hardware backend, and HMAC signature involving server-side factors (i.e., end-to-cloud two-factor signature). If the business requires application-layer end-to-cloud encryption, an end-to-cloud key negotiation mechanism can be added on top of this application; this application does not specifically limit this.

[0129] Phase Two - Server-Side Verification: No key is held; only signature verification is performed. Path and level are irrelevant. The server receives a set of plaintext application-layer data consisting of "evidence data + adoption level + downgrade reason + full signature". The server's verification process has a core premise: it does not possess, rely on, or require any device encryption keys or data encryption keys, nor does it need to decrypt any ciphertext.

[0130] All server-side verifications are based solely on the received plaintext data and signatures. In the server-side processing logic, the adoption level is only considered as a risk control feature in subsequent policy decisions after all signature verifications have passed; it is not used as a condition for parsing branches. This means that regardless of whether the photo adoption is L0 or L4, the verification code path executed by the server remains completely consistent. This is a concrete manifestation of downgrading without breaking data format compatibility on the server side: the server does not need to follow different verification branches based on the level; one set of code covers all levels.

[0131] This design also avoids a logical contradiction: if the server needs to perform different processing based on the level, it means that the server needs to understand or hold the device's hardware encryption keys, which contradicts the basic assumption of the hardware trust model, namely that the root of trust of the hardware backend should not be held or relied upon by the server. This application eliminates this contradiction from the architectural perspective by allowing the server to completely avoid touching the keys and only verify the signature.

[0132] The core intent of the aforementioned two-stage architecture is to completely decouple hardware trust on the client side from cloud service trust. The client side's responsibility is to complete key operations within the hardware backend and output signed, verifiable plaintext evidence. The cloud side's responsibility is to perform integrity and authenticity verification solely based on the signature and structured fields, without needing to understand or adapt to the hardware characteristics of any device. This division of labor makes the solution unaffected by platform differences. The server does not need to handle key escrow, nor does it need to adapt to different hardware backends. The parsing path remains completely consistent across all protection levels, resulting in extremely low operational costs.

[0133] In summary, this application has achieved at least the following technical effects: (1) Full coverage of a large number of heterogeneous devices and each can make the best use of its own capabilities. This application has a complete protection gradient from the highest hardware security level to the pure software minimum level. High-end devices can make full use of dedicated hardware security modules such as StrongBox and Secure Enclave to obtain the strongest protection. Low-end devices can still fall back to the software backend to complete the photo taking after all hardware level attempts fail, without interrupting the business due to the lack of hardware capabilities. This achieves full coverage of a large number of heterogeneous terminal devices on the market, and each device can obtain the corresponding level of protection within its own capabilities.

[0134] (2) Runtime probing detects false device claims and avoids selecting a non-existent protection level, resulting in runtime failure or attack. This application sets up a probing mechanism in both the key generation stage and the end-to-end loop stage, which can identify hardware capabilities that the device claims to support but does not actually have at runtime. Such cases are marked separately with the semantics of "false device capability" to avoid the terminal mistakenly selecting a non-existent protection level, which would lead to runtime failure. At the same time, it also prevents attackers from using false capabilities to deceive the system into adopting an insecure protection level.

[0135] (3) Downgrading does not damage the data format, the server-side parsing path remains consistent, cross-level compatibility is achieved, and maintenance costs are low. In this application, only the custodian of the key encryption key is changed during the downgrading process. The encapsulated structure of the data encryption key and the data format of the evidence snapshot ciphertext remain consistent across all protection levels. The server does not need to configure differentiated parsing logic for different levels. The same parsing path can be used to be compatible with encrypted evidence data of all levels, effectively reducing the maintenance and adaptation costs of the server.

[0136] (4) The reasons for downgrading are observable and diagnosable, and can be used as risk control signals for upper-level judgment. This application reports the reasons for downgrading in the form of structured enumeration fields along with the encrypted evidence data. The risk control side can use this to distinguish different failure scenarios such as missing interfaces, false capability reports, key failures, and timeouts, so as to achieve refined observation and diagnosis of the security status of the equipment, and map different reasons to different risk control handling strategies, thereby improving the accuracy of overall security decisions.

[0137] (5) Both the protection level and the reason for downgrade are incorporated into the signature, becoming verifiable attributes and supporting a hierarchical trust strategy. In this application, the adoption level and the reason for downgrade are used as extended fields of the evidence snapshot and participate in the field-by-field signature independently, making both immutable and verifiable attributes. The server can know the hardware protection strength and the reason for downgrade of the evidence while verifying the integrity of the evidence data, thereby upgrading the security trust assessment from a binary judgment of "trustworthy or untrustworthy" to a hierarchical trust model that implements differentiated strategies according to the level.

[0138] (6) The probe uses a one-time key and does not wear down the official key. This application generates the key used in the probe phase separately from the official protection key. The probe operation only consumes the one-time candidate key. After all verifications are passed, the official key encryption key is regenerated in the same session and the first key operation is performed. This ensures that the official key is in a clean state from the time of generation and has not been touched by the probe. This avoids the wear down of the official key state caused by repeated probes and extends the service life of the hardware security module.

[0139] (7) The false reporting list mechanism enables duplicate devices to avoid invalid attempts and reduces runtime overhead. This application constructs a false reporting list of device capabilities by aggregating multiple source reports in the cloud and using a dual threshold of model-level anomaly rate and the proportion of a single reporting source. When taking photos, devices of the same model can directly skip the level that has been independently verified as false by multiple parties, without having to repeatedly perform invalid attempts. This effectively reduces the key operation overhead and response latency of a large number of devices of the same model during runtime.

[0140] (8) Alongside the trust in the operating environment, they together constitute two verifiable dimensions of "tiered trust". The data protection level determined in this application reflects the tiering of the hardware security capabilities of the device. It is independent of and complementary to the trust in the operating environment. Together, they constitute two verifiable dimensions of the credibility of evidence data, enabling the server to comprehensively evaluate the credibility of evidence data from both the perspectives of device hardware capabilities and the security status of the operating environment, thus forming a more complete tiered trust system.

[0141] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0142] According to another embodiment, a device 700 for protecting photographic data is provided. Figure 7 This invention provides a schematic diagram of the structure of a device for protecting photographic data according to an embodiment of this application. Figure 7 As shown, the data protection device 700 includes: an acquisition unit 710, a probe unit 720, a determination unit 730, and an encryption unit 740, wherein: The acquisition unit 710 is used to acquire an evidence snapshot generated during the current photo taking, and the evidence snapshot is used to determine the authenticity of the photo taken during the current photo taking; The probing unit 720 is used to perform step-by-step key operation probing on multiple preset data protection levels using a preset probing strategy to determine the data protection level adopted for this photo capture. The determining unit 730 is used to determine the multi-layer protection key of the evidence snapshot based on the data protection level of the data acquired in this photo taking, using a predefined multi-layer key structure; The encryption unit 740 is used to encrypt the evidence snapshot using the multi-layer protection key of the evidence snapshot and output structured encrypted evidence data.

[0143] In some embodiments of this application, the preset multiple data protection levels include the following levels of protection capabilities from strong to weak: independent security chip level, trusted execution environment level, vendor proprietary security camera level, protected software key level, and pure software protection level.

[0144] In some embodiments of this application, the probing unit 720 is specifically used to: perform end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level, wherein the current probing level is one of a plurality of preset data protection levels; if the key operation probing result of the current probing level is successful, then the current probing level is used as the data protection level for this photo acquisition; if the key operation probing result of the current probing level is unsuccessful, then the probing is downgraded to the next data protection level until the data protection level for this photo acquisition is determined.

[0145] In some embodiments of this application, the probing unit 720 is specifically used to: query whether the key service interface for the current probing level exists; if the key service interface for the current probing level exists, generate a probing key for the current probing level in the key backend of the current probing level, and execute a complete encryption / decryption loop or signature verification loop using the probing key for the current probing level; if the encryption / decryption loop or the signature verification loop is executed successfully, determine that the key operation probing result for the current probing level is a successful probing; if any of the following occurs: the key service interface for the current probing level does not exist, the probing key generation fails, the encryption / decryption loop execution fails, or the signature verification loop execution fails, determine that the key operation probing result for the current probing level is a failed probing.

[0146] In some embodiments of this application, the probing unit 720 is specifically used to: generate a key proof of the probing key of the current probing level when the current probing level supports key proof; and determine the key operation probing result of the current probing level as a probing failure when the key proof of the probing key cannot be generated or the proof chain verification of the key proof fails.

[0147] In some embodiments of this application, the probing unit 720 is specifically configured to: when the current probing level supports key proof, generate a key proof of the probing key for the current probing level at the key backend of the current probing level, and write the one-time challenge parameter issued by the server into the challenge parameter field of the key proof; send the key proof of the probing key for the current probing level and the one-time challenge parameter to the server, so that the server performs anti-replay verification based on the one-time challenge parameter and obtains the anti-replay verification result; if the anti-replay verification result is successful, then the key operation probing result of the current probing level is adopted; if the anti-replay verification result is unsuccessful, then the key operation probing result of the current probing level is not adopted, and the probing is downgraded to the next data protection level.

[0148] In some embodiments of this application, the proof chain of the key proof for the current probing level carries an application binding field. The probing unit 720 is specifically used to: extract the application binding field from the proof chain of the key proof for the current probing level; compare the extracted application binding field with the application information actually running during the current photo capture; if the extracted application binding field matches the application information actually running during the current photo capture, then the key operation probing result for the current probing level is adopted; otherwise, the key operation probing result for the current probing level is not adopted, and the probing is downgraded to the next data protection level.

[0149] In some embodiments of this application, the probing unit 720 is specifically used to: generate a probing failure semantic event based on the reason for the probing failure and report it when the key operation probing result of the current probing level is a probing failure, and downgrade to the next data protection level for key operation probing; wherein, the reason for the probing failure is any one of the following: interface does not exist, device capability is falsely reported, key is revoked, user authentication is revoked, device enters an abnormal security state, probing operation times out, and other probing operation failure situations.

[0150] In some embodiments of this application, the device 700 further includes: a caching unit, configured to cache the key operation probing results of each probing level using a preset caching strategy; the probing unit 720 is specifically configured to: search in the cached key operation probing results according to the current probing level; if the key operation probing result of the current probing level is found in the cached key operation probing results, then the cached key operation probing result is used directly; otherwise, end-to-end key operation probing is performed on the current probing level to obtain the key operation probing result of the current probing level.

[0151] In some embodiments of this application, the device 700 further includes: a signature unit, configured to sign the current probing level and device identification information when the failure reason for the current probing level is false reporting of device capabilities; and a reporting unit, configured to report the current probing level, the device identification information, and the corresponding signature to the server, so that the server can construct or update the list of falsely reported device capabilities; the probing unit 720 is specifically configured to: obtain the list of falsely reported device capabilities; search the list of falsely reported device capabilities according to the device identification information of the current probing level; if the device identification information of the current probing level can be found in the list of falsely reported device capabilities, then directly downgrade to the next data protection level for key operation probing; otherwise, perform end-to-end key operation probing on the current probing level to obtain the key operation probing result of the current probing level.

[0152] In some embodiments of this application, the predefined multi-layer key structure is a two-layer key structure, which includes an upper-layer key encryption key and a lower-layer data encryption key. Both the key encryption key and the data encryption key are generated and managed in the backend of the key for the data protection level of the data captured in this photo. The key encryption key is used to encrypt the data encryption key into a packaged data encryption key, and the data encryption key is used to encrypt the evidence snapshot into evidence snapshot ciphertext.

[0153] In some embodiments of this application, the determining unit 730 is specifically used to: use the trial key corresponding to the data protection level of the data captured in this photo as the key encryption key; and generate the data encryption key using a random symmetric key generation algorithm after the key of the data protection level of the data captured in this photo.

[0154] In some embodiments of this application, the encryption unit 740 is specifically used for: encrypting the evidence snapshot using the data encryption key to obtain evidence snapshot ciphertext; encapsulating the data encryption key using the key encryption key to obtain encapsulated data encryption key; performing field-by-field signatures on the evidence snapshot ciphertext, the encapsulated data encryption key, the data protection level adopted in this photo and the downgrade reason to obtain an extended field-level signature of the evidence snapshot; and using the evidence snapshot ciphertext, the encapsulated data encryption key, the data protection level adopted in this photo, the downgrade reason and the extended field-level signature of the evidence snapshot as the structured encrypted evidence data.

[0155] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0156] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0157] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. For example... Figure 8As shown, the electronic device includes one or more processors (or processing units), and may also include one or more memories coupled to the processor, and may also include a communication module coupled to the processor.

[0158] A communication module can be used to communicate with other devices or apparatuses, such as sending or receiving data and / or signals. A communication module may have at least one communication module for communication. A communication module may include any interface necessary for communicating with other devices. Exemplarily, a communication module may be a transceiver, circuit, bus, module, or other type of communication module.

[0159] The processor may include, but is not limited to, one or more of the following: a general-purpose computer, a special-purpose computer, a microcontroller, a digital signal processor (DSP), or a controller-based multi-core controller architecture. The device may have multiple processors, such as application-specific integrated circuit (ASIC) chips, which are time-dependent on a clock synchronized with the main processor.

[0160] The memory may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, at least one of the following: read-only memory (ROM), electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), or other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, at least one of the following: random access memory (RAM), or other volatile memories that do not persist during the duration of a power outage.

[0161] A computer program consists of computer-executable instructions that are executed by an associated processor. Programs can be stored in ROM. A processor can perform any appropriate action and processing by loading the program into RAM.

[0162] Possible implementations of this application can be achieved through a program, enabling the communication device to execute any of the processes discussed in the foregoing embodiments. Possible implementations of this application can also be achieved through hardware or a combination of software and hardware.

[0163] In some implementations, the program may be tangibly contained in a computer-readable storage medium, which may include in a device (such as in memory) or other storage device accessible by the device. The program may be loaded from the computer-readable storage medium into RAM for execution. The computer-readable storage medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0164] This application also provides a computer-readable storage medium storing computer instructions or program code thereon, which, when executed by a processor, causes the processor to perform the methods and functions involved in any of the above embodiments. A computer-readable medium can be any tangible medium that contains or stores a program for or relating to an instruction execution system, apparatus, or device. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. More detailed examples of computer-readable storage media include electrical connections with one or more wires, magnetic media (e.g., disks, floppy disks, hard disks, magnetic tapes, magnetic storage devices), optical media (e.g., optical storage devices, DVDs), semiconductor media (e.g., solid-state drives), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), or any suitable combination thereof.

[0165] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. Embodiments of this application also provide at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. This computer program product includes one or more computer-executable instructions, such as instructions included in a program module, which execute in a device on a target real or virtual processor to perform the processes, methods, and functions involved in any of the above embodiments. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0166] This application also proposes a computer program product, including a computer program or instructions that, when run on a computer, cause the computer to perform the processes, methods, and functions described in the above embodiments. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided as needed. The machine-executable instructions for the program modules can be executed locally or in a distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0167] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software, which can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or represented using some other illustration, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as, as non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0168] It should be noted that although embodiments of this application have been described above with reference to the accompanying drawings, these embodiments are not independent of each other, and they can be combined to obtain other embodiments. The methods, situations, categories, and classifications of embodiments in this application are only for the convenience of description and should not constitute a special limitation. Various methods, categories, situations, and features in embodiments can be combined with each other if logically consistent. The various embodiments of this application can be arbitrarily combined to achieve different technical effects. The embodiments of this application will not list various combinations.

[0169] Furthermore, although the operation of the methods of this disclosure is described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Rather, the steps depicted in the flowcharts may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps. It should also be noted that the features and functions of two or more devices according to this disclosure may be embodied in one device. Conversely, the features and functions of one device described above may be further divided and embodied by multiple devices.

[0170] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0171] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for protecting photographic data, characterized in that, The method includes: Obtain an evidence snapshot generated during this photo taking, and the evidence snapshot is used to determine the authenticity of the photo taken. By using a preset probing strategy, key operations are performed at each of the preset data protection levels to determine the data protection level adopted for this photo capture. Based on the data protection level adopted in this photo shoot, the multi-layer protection key of the evidence snapshot is determined using a predefined multi-layer key structure; The evidence snapshot is encrypted using a multi-layered protection key to output structured encrypted evidence data.

2. The method according to claim 1, characterized in that, The preset data protection levels include the following levels of protection capabilities, from strongest to weakest: independent security chip level, trusted execution environment level, vendor-specific security camera level, protected software key level, and pure software protection level.

3. The method according to claim 1, characterized in that, The method of using a preset probing strategy to perform step-by-step key operation probes on multiple preset data protection levels to determine the data protection level adopted for this photo capture includes: Perform end-to-end key operation probing on the current probing level to obtain the key operation probing result for the current probing level, where the current probing level is one of a set of multiple data protection levels. If the key operation test result of the current test level is successful, then the current test level will be used as the data protection level for this photo capture. If the key operation attempt at the current attempt level fails, the process is downgraded to the next data protection level until the data protection level for this photo is determined.

4. The method according to claim 3, characterized in that, The process of performing end-to-end key operation probing at the current probing level to obtain the key operation probing result at the current probing level includes: Check if the key service interface for the current probing level exists; If the key service interface for the current probing level exists, then a probing key for the current probing level is generated in the key backend of the current probing level, and a complete encryption / decryption loop or signature verification loop is executed using the probing key for the current probing level. If the encryption / decryption loop or the signature verification loop is executed successfully, then the key operation test result of the current test level is determined to be a successful test. If any of the following occurs: the current probing level does not have a key service interface, the probing key generation fails, the encryption / decryption loop fails to execute, or the signature verification loop fails to execute, then the key operation probing result for the current probing level is determined to be a probing failure.

5. The method according to claim 4, characterized in that, The process of performing end-to-end key operation probing at the current probing level to obtain the key operation probing result at the current probing level includes: If the current probing level supports key proof, a key proof for the probing key of the current probing level is generated at the key backend of the current probing level. If a key proof for the probe key cannot be generated or the proof chain verification for the key proof fails, the probe result for the key operation at the current probe level is determined to be a probe failure.

6. The method according to claim 5, characterized in that, The process of performing end-to-end key operation probing at the current probing level to obtain the key operation probing result at the current probing level includes: If the current probing level supports key proof, a key proof for the probing key of the current probing level is generated in the key backend of the current probing level, and the one-time challenge parameter issued by the server is written into the challenge parameter field of the key proof. The key proof of the current probing key and the one-time challenge parameter are sent to the server so that the server can perform anti-replay verification based on the one-time challenge parameter and obtain the anti-replay verification result. If the anti-replay verification result is successful, then the key operation test result of the current test level is adopted; If the anti-replay verification result is that the verification fails, the key operation test result of the current test level will not be adopted, and the key operation test of the next data protection level will be downgraded.

7. The method according to claim 5, characterized in that, The proof chain of the key proof for the current probing level carries an application binding field. The end-to-end key operation probing of the current probing level to obtain the key operation probing result for the current probing level includes: Extract the application binding field from the proof chain of the key proof of the current probing level; The extracted application binding fields are compared with the application information actually running during this photo capture. If the extracted application binding field matches the application information actually running in this photo, then the key operation test result of the current test level will be adopted. Otherwise, the key operation test result of the current test level will not be adopted, and the key operation test of the next data protection level will be downgraded.

8. The method according to any one of claims 3 to 7, characterized in that, The method of using a preset probing strategy to perform step-by-step key operation probes on multiple preset data protection levels to determine the data protection level adopted for this photo capture includes: If the key operation attempt at the current attempt level fails, a key operation attempt failure semantic event is generated based on the reason for the failure and reported, and the attempt is downgraded to the next data protection level. The reasons for the failure of the probe include any one of the following: the interface does not exist, the device capability is falsely reported, the key is revoked, the user authentication is revoked, the device enters an abnormal security state, the probe operation times out, and other probe operation failure situations.

9. The method according to any one of claims 3 to 7, characterized in that, The method further includes: The results of key operations at each probing level are cached using a preset caching strategy; The method of using a preset probing strategy to perform step-by-step key operation probes on multiple preset data protection levels to determine the data protection level adopted for this photo capture includes: Retrieve from the cached key operation probing results based on the current probing level; If the key operation probing result for the current probing level is found in the cached key operation probing results, then the cached key operation probing result is used directly. Otherwise, perform end-to-end key operation probing on the current probing level to obtain the key operation probing result for the current probing level.

10. The method according to claim 8, characterized in that, The method further includes: If the failure of the current test level is due to false reporting of equipment capabilities, the current test level and equipment identification information are signed. The current probing level, the device identification information, and the corresponding signature are reported to the server so that the server can build or update the list of falsely reported device capabilities. The method of using a preset probing strategy to perform step-by-step key operation probes on multiple preset data protection levels to determine the data protection level adopted for this photo capture includes: Obtain a list of equipment with falsely reported capabilities; Based on the equipment identification information of the current testing level, a search is performed in the list of falsely reported equipment capabilities; If the device identification information of the current testing level can be found in the list of falsely reported device capabilities, the device will be downgraded directly to the next data protection level for key operation testing. Otherwise, perform end-to-end key operation probing on the current probing level to obtain the key operation probing result for the current probing level.

11. The method according to claim 1, characterized in that, The predefined multi-layer key structure is a two-layer key structure, which includes an upper-layer key encryption key and a lower-layer data encryption key. Both the key encryption key and the data encryption key are generated and managed in the backend of the data protection level key adopted in this photo. The key encryption key is used to encrypt the data encryption key into a packaged data encryption key, and the data encryption key is used to encrypt the evidence snapshot into evidence snapshot ciphertext.

12. The method according to claim 11, characterized in that, The process of determining the multi-layered protection key for the evidence snapshot based on the data protection level acquired in this photo capture, using a predefined multi-layered key structure, includes: The probe key corresponding to the data protection level adopted in this photo will be used as the encryption key; In the backend of the data protection level key adopted in this photo shoot, the data encryption key is generated using a random symmetric key generation algorithm.

13. The method according to claim 11, characterized in that, The step of encrypting the evidence snapshot using a multi-layered protection key to output structured encrypted evidence data includes: The evidence snapshot is encrypted using the data encryption key to obtain the ciphertext of the evidence snapshot; The data encryption key is encapsulated using the key encryption key to obtain the encapsulated data encryption key; The evidence snapshot ciphertext, the data encryption key of the encapsulated state, the data protection level adopted in this photo and the reason for downgrading are signed field by field to obtain the extended field-level signature of the evidence snapshot; The encrypted evidence data consists of the encrypted evidence snapshot, the data encryption key of the encapsulated state, the data protection level of the data adopted in this photo, the reason for the downgrade, and the extended field signature of the evidence snapshot.

14. A device for protecting photographic data, characterized in that, The device includes: An acquisition unit is used to acquire an evidence snapshot generated during this photo taking, and the evidence snapshot is used to determine the authenticity of the photo taken during this photo taking; The probing unit is used to perform step-by-step key operation probing on multiple preset data protection levels using a preset probing strategy to determine the data protection level adopted for this photo capture. The determining unit is used to determine the multi-layer protection key of the evidence snapshot based on the data protection level of the data acquired in this photo capture, using a predefined multi-layer key structure; An encryption unit is used to encrypt the evidence snapshot using a multi-layered protection key, and output structured encrypted evidence data.

15. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 13.

16. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program performs the steps of the method according to any one of claims 1 to 13.

Images