Many thanks for your detailed review and insightful comments. We will carefully consider your recommendations to improve the manuscript and respond to your questions in detail, hoping to address your concerns.

$\textcolor{red}{{\rm Q.1}}$ Secret Key and User

Who is the user ?

In the main text, "user" refers to the "model trainer" or, in the case of a dishonest trainer, the "attacker." We provide a detailed analysis of this in the General Response $\textcolor{red}{{\rm GR.1.1}}$.

Who generate the key ?

In $\textcolor{red}{{\rm GR.5}}$, we provide a detailed analysis of various scenarios regarding who is responsible for generating the key. Besides, in $\textcolor{red}{{\rm GR.3}}$ we elaborate on how to implement the whole verificaition framework.

Planned Revisions

We sincerely thank you for your valuable comments on this part. We will standardize the terminology throughout the manuscript by replacing "user" with "trainer". Considering the page constraints in the main text, we will include the implementation details in the appendix to better support the verification protocol described in the main text.

$\textcolor{red}{{\rm Q.2}}$ Definition of Harmlessness

ndeed, as you pointed out, PP may make probes more susceptible to MIA attacks. However, we believe that in the TDP scenario, the focus is on the dataset's trustworthiness rather than its privacy. Since the model trainer has already publicly declared the use of dataset $D$, o gain trust, users can clearly identify the members of $D$.

Therefore, we consider the focus on performance compromising, rather than privacy, to be reasonable for the definition of harmlessness in this work. We provide a detailed explanation of the dataset's nature in $\textcolor{red}{{\rm GR.2}}$, emphasizing the key distinctions between TDP and dataset provenance tasks. Additionally, we included an example in $\textcolor{red}{{\rm GR.1.2}}$ to further illustrate these differences. We hope this helps address your concerns.

In terms of performance, exactly, AP slightly hurts the performance of probes. Similarly, UP and TP affect the accuracy of the probes themselves. However, our primary focus is on the performance of the test set, as in deployment scenarios, models are most likely to encounter non-training data. Generalization performance is thus more critical.

The extensive experimental results in $\textcolor{green}{{\rm Table 2}}$ demonstrate that the impact on generalization is negligible, mainly due to the small proportion of probes in the dataset. Therefore, we believe that the harmlessness of AP, UP, and TP is within an acceptable range.

Certainly, we deeply appreciate your valuable opinion. Investigating whether applying overfitting to certain samples might introduce additional security risks in the TDP scenario is indeed a meaningful topic for further exploration. Although it may go beyond the scope of the current work, we plan to delve into this aspect in future studies.

$\textcolor{red}{{\rm Q.3}}$ Probe Type Selection Strategy

Why different probe?

Since TDP is a completely new task with no available baselines, this work, inspired by MIA and poisoning attacks, designs four types of probes primarily to serve as baselines for each other. The goal is to provide TDP framework users with a reference for selecting probes by comparing their performance. Similarly, we designed four scoring methods for probes and demonstrated through experiments that Mentr achieves the best performance.

Which probe to be used?

From the comparison of the results in $\textcolor{green}{{\rm Table 2}}$ and $\textcolor{green}{{\rm Table 3}}$, it is evident that PP and AP exhibit better generalizability. As dataset complexity increases (SVHN → CIFAR-10 → CIFAR-100 → TinyImageNet-200), the overfitting effect on probes becomes significantly stronger, demonstrating their applicability to more practical datasets.

In contrast, UP and TP may face the risk of failure when dealing with complex datasets, as their effectiveness is more heavily influenced by the model's ability to fit the dataset. However, in terms of robustness, UP and TP offer better security compared to AP and PP.

Planned Revisions

We will enhance the discussion on probe type selection in the manuscript. Additionally, combining the strengths of the four types of probes to achieve a comprehensively better type is certainly a valuable research direction. While it may slightly exceed the scope of the current paper, we will consider exploring it in future work.

Thank you very much for your thorough review and valuable feedback, particularly your suggestions regarding experimental evaluation and related work. We will carefully consider your advice to improve our work. In the following sections, we provide detailed responses to your questions in the hope of addressing your concerns.

$\textcolor{red}{{\rm Q.1}}$ Expand the evaluation

Thank you for your suggestion. We will take it into account to improve our adaptive attack and case studies experiments. Due to time constraints, we may not be able to complete and organize all the results during the rebuttal period. We sincerely apologize for this in advance, but we would try our best include these experiments in the final revised version.

$\textcolor{red}{{\rm Q.2}}$ Comparison To DeepTaster

Principle of DeepTaster: similar to DI

We analyzed the principle of DeepTaster. In terms of classification, it employs a DNN fingerprinting technique different from watermarking. Broadly speaking, it utilizes specific techniques to compute the response differences of a model to certain samples, thereby extracting the model's fingerprint, and then train an additional classifier to make determinations. This principle is almost identical to that of DI.

Therefore, we believe that DeepTaster shares similar characteristics with DI: it is non-invasive but requires a high verification overhead (as a classifier needs to be trained individually for each verification). Additionally, it struggles to distinguish between two similar data distributions (e.g., $D$ and $D^*$ with minimal modifications).

Planned Revisions

We will include an introduction and discussion of DeepTaster in the related work section.

$\textcolor{red}{{\rm Q.3}}$ Other Questions

• It is not stated what scores are shown in gray in Table 4.
• Add a clear explanation of what the gray scores represent in the Table 4 caption or in the accompanying text discussing Table 4. This would help improve the clarity of their results presentation.

The gray scores in $\textcolor{green}{{\rm Table4}}$ represents the scores for each validation, with watermarking representing the predicted probabilities, and DI and Data Probe indicating the p-values.

As it conveys the same meaning as $\textcolor{green}{{\rm Table 6}}$, we directly referenced $\textcolor{green}{{\rm Table 6}}$'s explanation in $\textcolor{green}{{\rm Table~4}}$ due to space constraints. We will work on refining and improving the explanation in this caption.

---

• In the adaptive attack experiment, the difference between the data D Vs D* is not clear.
• Provide a more detailed explanation of how D* differs from D in the adaptive attack scenario. Eg. include a specific example to clarify this important aspect of the experimental setup.

In the adaptive attack experiment, we assume that the difference between $D$ and $D^*$ is minimal, such as only a single sample being modified.

To facilitate large-scale experiments without compromising the integrity of the framework’s principles, in the adaptive attack evaluation, we directly control the random seeds as a substitute for dataset modification and hashing operations.

Specifically, even minimal differences in the dataset can result in a change of the seed (as illustrated in $\textcolor{green}{{\rm Figure~6}}$ of the case study). During training, we use seed $s_1$ (simulating the scenario of training with $D^*$), and then attempt to forge the probe corresponding to seed $s_2$ (representing training with $D$)

We will adjust and better elaborate on this experimental setup in the main text.

---

Typos/etc:

• in the abstract: “data-drobe-based".
• Please check the definition of Conf(M,x) on page 7. What is the maximum taken over?
• Table 4 caption: “socres” should be “scores”

Due to space constraints, we have provided an explanation of this part in $\textcolor{green}{{\rm Appendix.C}}$. Similarly, we will work on refining and improving this explanation in the main text.

Thank you for your suggessions. We will address these typos in the revised version and make every effort to correct any other existing typos.

Upon our review, the definition of Conf(M,x) is correct, representing the maximum taken over the logits of the model's output. The design of this function is motivated by [1]

[1] Ml-leaks: Model and data independent membership inference attacks and defenses on machine learning models.

We deeply appreciate your thorough review and constructive feedback, as well as your kind acknowledgment of our work. We will carefully consider your recommendations to improve the manuscript and respond to your questions in detail in the following sections.

$\textcolor{red}{{\rm Q.1}}$ Motivation of the Work

My main concern is the motivation and threat model is not clear to me. The paper proposed a method to verify the training was performed on 'a credit dataset D' such that 'the model trainer can gain trust from the users'. This claim seems to be not convincing to me. Why a user can have extra trust if the model is trained a specific dataset? What is the goal of the model user? It would be better to show some real examples to help clarify it.

In Genral Response $\textcolor{red}{{\rm GR.1}}$, we provide a detailed introduction to the potential application scenarios of TDP, illustrated with an example based on the real-world model publishing platform Hugging Face.

We further build on this example to explain "why a user can have extra trust if the model is trained on a specific dataset.". More precisely, in the TDP problem, the focus of both the verifier and the model user is not on which dataset is used but rather on how the dataset is used. Therefore, the statement is more accurately expressed as: "a user can have extra trust if the model is trained on a specific dataset without modification."

Taking CIFAR-10 as an example, as mentioned in $\textcolor{red}{{\rm GR.1}}$, our case study ($\textcolor{green}{{\rm Figure~6}}$ in the manuscript) experimentally demonstrates that an attacker can modify a small portion of CIFAR-10 samples to embed backdoors while still claiming that the model is trained on pristine CIFAR-10. Such a model can bypass existing dataset provenance-based techniques. If the model user trusts the attacker’s claim and deploys the model, it clearly introduces significant security risks.

Conversely, if there is a mechanism—such as the TDP task proposed in this paper—that can distinguish whether CIFAR-10 was modified during training, users would naturally prefer the model without modifications. This provides the model with extra trust.

In summary, the TDP framework we propose is specifically designed to verify that the training was performed on "a credit dataset $D$" without modification. Here, $D$ can be CIFAR-10 or any other dataset. We also provide a detailed discussion on the "credit" property of $D$ in $\textcolor{red}{{\rm GR.2}}$.

$\textcolor{red}{{\rm Q.2}}$ More Complex Scenarios

Planned Revisions

Thank you very much for the insightful suggestion. We indeed recognize that, in real-world application scenarios, there will be more complex issues that do not fully align with our foundational assumptions. Due to the page constraints of the manuscript, we plan to expand this discussion in the revised version, either in the discussion section or the appendix.

Extension to Multiple Datasets

We consider this can be broadly divided into two situations:

1. Using two similar datasets, merging them as a single unit for model training.
2. Pretraining on a large, general-purpose dataset (e.g., using ImageNet to pretrain the backbone) followed by fine-tuning on a smaller domain-specific dataset.

Our approach can be conveniently extended to accommodate the first scenario. For example, we can treat two datasets, $D_1$ and $D_2$ , as a single unit and perform a single data probe implantation (by concating them). During verification, the trainer simply declares to the verifier that the model was trained using $D_1 + D_2$.

For the second situation, our approach may have certain limitations. For instance, if probes are first embedded when trained with $D_1$ and then additional probes are embedded during fine-tuning with $D_2$, the distribution may indeed change, potentially affecting the stability of the $D_1$'s probes. We acknowledge that this is a meaningful topic for further exploration and plan to investigate it in future work.

Adapting to Data Augmentation

Our algorithm can be adapted to support basic data augmentation. Specifically, we compute the hash on the complete dataset without any augmentation, select the data probes, and apply specific treatments (e.g., increasing the selection probability for PP). During training, data augmentation is allowed as part of the trainning process. The implementation of this adaptation can also be understood in conjunction with the trusted-training wrapper described in $\textcolor{red}{{\rm GR.3}}$.

In fact, all experimental results in this study were obtained with data augmentation techniques such as horizontal flipping and random cropping during training (as detailed in $\textcolor{green}{{\rm Appendix C}}$). When employing more extensive augmentation or filtering techniques, the situation may become more complex and warrants further experimental exploration. We plan to consider this as future work.

We are deeply thankful for your detailed review and constructive feedback. Your suggestions on the threat model and framework implementation have indeed pointed out some clarity issues in our manuscript. These aspects were not fully elaborated due to space constraints. We will carefully consider your feedback and revise the corresponding sections accordingly.

In the following sections, we provide detailed answers to your questions, aiming to address your concerns sufficiently, and we we kindly ask you to reconsider the evaluation of our work in light of the improvements.

$\textcolor{red}{{\rm Q.1}}$ Inconsistent Threat Model Assumptions

• ... At the same time, the threat model assumes that the same dishonest attacker voluntarily sticks to the exact verification protocol...
• In practical terms, this means it is easy for the attacker to bypass the proposed verification approach...

Mandatorily but not voluntarily

In our proposed TDP, we assume that the attacker's (trainer's) watermark embedding operation is mandatorily enforced and could not be modified by the trainer. We provide a detailed explanation of how this can be implemented, as well as its feasibility and rationale, in General Response $\textcolor{red}{{\rm GR.3}}$ Implementation of TDP

Planned Revisions

We will provide a clearer explanation of the above characteristics in the threat model and implementation section. Considering the space constraints in the main text, we may include detailed discussions on the implementation in the appendix.

$\textcolor{red}{{\rm Q.2}}$ The Dataset Has to be Public

Since the data contains a significant part of the value, the trainer may be reluctant to publish it. Licenses and intellectual property may also work against this.

The nature of datasets in TDP is Turstworthy instead of private. We provide a detailed explanation in $\textcolor{red}{{\rm GR.2}}$.

There is indeed a trade-off between dataset transparency/trustworthiness, and dataset privacy/copyright. However, the latter is a primary focus of dataset provenance, while TDP, as explored in this paper, emphasizes the former. Thus, TDP and dataset provenance are fundamentally different problems.

We will incorporate your suggestion and add this discussion in the introduction or discussion section of the paper.

$\textcolor{red}{{\rm Q.3}}$ Secret Key and User

Who is the user ?

In the main text, "user" refers to the "model trainer" or, in the case of a dishonest trainer, the "attacker." We provide a detailed analysis of this in $\textcolor{red}{{\rm GR.1.1}}$.

Why the secret key is necessary ?

In $\textcolor{red}{{\rm GR.4}}$, we conduct a detailed analysis of the security of the system under both keyed-hash and non-keyed-hash scenarios. The conclusion is as follows:

Keyed-hash provides superior security compared to common hash functions. When the details of T-Train are partially or fully exposed, only keyed-hash can enhance security by concealing the key.

The effective mechanism is that even if the attacker knows the complete verification details, such as the hash function and probe types used, it remains highly difficult to brute-force and select the correct probe without knowing the key.

How to hide the key ?

In $\textcolor{red}{{\rm GR.5}}$, we provide a detailed analysis of various scenarios regarding who is responsible for generating the key and propose a potential implementation scheme for situations where the key needs to be concealed. We hope this addresses your concerns.

Planned Revisions

We sincerely thank you for your valuable comments on this part. We will standardize the terminology throughout the manuscript by replacing "user" with "trainer". Considering the page constraints in the main text, we will include additional security analysis and implementation details in the appendix to support the keyed-hash mechanism in the main text.

$\textcolor{red}{{\rm GR.4}}$ Detailed Security Analysis of TDP

$\textcolor{red}{{\rm GR.4.1}}$ Analysis of different dangerous levels

Based on the reviewers' questions, we categorize the security of TDP into three $\textcolor{blue}{{\rm Dangerous~Levels (DL):}}$ depending on the malicious trainer's knowledge of the verification mechanism. For each Level, we discuss two cases: (A) the attacker does not know their key, and (B) the attacker knows their key. Additionally, we present case (C), where a keyed-hash is not used, for comparison. The comprehensive comparison is illustrated in THIS CHART ($\leftarrow$ recommend clicking the provided link to view it).

---

$\textcolor{blue}{{\rm DL~I:}}$ No-info. The attacker is completely unaware of the details of the verification mechanism. Evidently, I-A, I-B, and I-C are secure.

$\textcolor{blue}{{\rm DL~II:}}$ Partial-info. The trainer has partial knowledge of the verification mechanism, such as knowing about the hash-based data probe embedding strategy but not the specific hash function used. At this point, the attacker may adopt a brute-force strategy, such as repeatedly trying different hash functions in an attempt to guess the actual probe. Thus, both II-B and II-C carry certain security risks. However, if the key remains inaccessible to the attacker (II-A), security can still be ensured.

$\textcolor{blue}{{\rm DL~III:}}$ Full-info. This is the worst-case scenario, where the attacker is fully aware of all the details of the verification mechanism. In III-B and III-C, as noted by the reviewers, the attacker could indeed adopt a more thorough attack strategy: bypassing the aforementioned wrapper entirely and directly embedding probes of $D$ during training, thereby undermining the verification mechanism. However, this assumption grants the attacker excessive power and essentially equates to allowing them to manipulate the Trusted Training process (refer to the discussion in $\textcolor{red}{{\rm GR.3.2}}$). Nevertheless, if the trainer does not know the key (III-A), it remains highly unlikely for them to select the correct probe, thereby ensuring security.

---

$\textcolor{red}{{\rm GR.4.2}}$ Significance of the Proposed Adaptive Attack

In our experimental evaluation, we designed a Forge Probe Attack (FPA) ($\textcolor{green}{{\rm L465}}$). After considering the reviewers' feedback, we recognize that certain parts of the discussion were indeed unclear. We will address and clarify these issues in the revised version.

FPA should not correspond to the III-B scenario, as this grants the attacker overly strong assumptions and, to some extent, contradicts the assumptions of this work. Instead, FPA corresponds to II-B and similar scenarios, where the attacker may rely on brute-force strategies to infer the actual probes. In this case, fully training the model while attempting different probe would be highly time-consuming. In contrast, FPA provides a highly efficient attack approach, as it only fine-tunes the model on probe samples (e.g., approximately 1% of the original dataset size). This makes it more feasible for the attacker to brute-force the correct result. Therefore, $\textcolor{green}{{\rm Table~3}}$ in the manuscript essentially demonstrates the robustness of the system when the attacker guesses correctly.

In summary, we draw the following two conclusions:

1. Keyed-hash outperforms common hash functions. While the security of both is identical when the trainer knows the key, in higher-risk scenarios (II and III), the keyed-hash provides an additional option to enhance security by concealing the key.
2. Hiding the key from attacker improves the security. Our experiments on the FPA attack demonstrate that attackers (trainers) can employ a quick testing strategy to guess probes, with PP and AP probes facing higher risks. Concealing the key significantly expands the search space, making it much harder for the attacker to guess correctly.

Additionally, more complex hash function strategies can be designed (e.g., combining the results of two different hash algorithms following specific rules) or new probe types can be developed to effectively increase the search space and reduce the likelihood of attackers deducing the details of the verification mechanism.

$\textcolor{red}{{\rm GR.3}}$ Possible Practical Implementation of TDP

We first review and summarize the core verification mechanism of the verifier in TDP, followed by an analysis of how to implement the proposed Trusted Training (T-train) on the trainer side.

$\textcolor{red}{{\rm GR.3.1}}$ Core verification mechanism

The core principle behind the verifier’s certification process is the detection of specific data probes within the model provided by the trainer.

$\textcolor{red}{{\rm GR.3.2}}$ Implementation of T-Train

Our requirement for additional operation $\mathbb{O}$ in T-Train is that it must be an automated process that cannot be manipulated by the trainer.

Here, we provide additional details that may not have been fully explained in the main text due to space constraints:

---

$\textcolor{blue}{{\rm 1.Key~Initialization:}}$ We assume the key is generated by the trainer, and the trainer has control over it. For instance, the key $k$ can be generated using a specific key generation function, ${\rm KeyGen()}$.

$\textcolor{blue}{{\rm 2.TrustedTraining~Wrapper:}}$ Using a commonly used deep learning framework like PyTorch as an example, the dataset/dataloader module can be wrapped using a verifier-provided wrapper module. This wrapper would automatically execute the T-Train process described in the paper, including probe selection and probe embedding. This is feasible because probe embedding typically involves only minor modifications to certain sample attributes, such as increasing the sampling probability of specific samples. Therefore, it is decoupled from the subsequent training optimization process and the model's framework.

$\textcolor{blue}{{\rm 3. Verification:}}$ The trainer employs the aforementioned wrapper to complete model training and submits the trained model along with the key to the verifier for validation.

---

The key prerequisite for the TDP framework to function effectively is that the wrapper must not be "compromised" by the trainer. Specifically, the trainer must not be able to manipulate the steps within the wrapper, particularly the process from handling the training dataset $D$ to probe selection.

Otherwise, it is evident that a counterexample can arise: the attacker could arbitrarily tamper $D \rightarrow D^*$, but during the probe embedding phase, directly embed probes of $D$ and claim "trained on $D$". In this way, an attacker could easily undermine the entire verification framework (as also pointed out by Reviewer $\textcolor{purple}{{\rm 5EGH}}$, $\textcolor{teal}{{\rm stcP}}$. $\textcolor{navy}{{\rm ty3A}}$). This is precisely why, in the manuscript, we emphasize in the attacker capability assumption section ($\textcolor{green}{{\rm L192}}$) that the attacker should not be able to modify the additional operation $\mathbb{O}$ (the wrapper in this case).

$\textcolor{red}{{\rm GR.3.3}}$ Main Concerns Regarding T-Train

The primary concerns that reviewers and readers might have regarding the aforementioned wrapper can be summarized as follows:

$\textcolor{blue}{{\rm Q1.}}$ How to ensure that the trainer is compelled to use the wrapper in T-Train ?

$\textcolor{green}{{\rm A1.}}$ Due to the presence of the verification mechanism, only models with correctly embedded probes can pass the verification. Therefore, if the trainer wishes to utilize the verification service, he must use the trusted training wrapper.

$\textcolor{blue}{{\rm Q2.}}$ How to ensure that the trainer cannot compromise the wrapper in T-Train ?

$\textcolor{green}{{\rm A2.}}$ This is perhaps the most challenging step in implementing the framework, especially considering the scenario where the wrapper's code is entirely open source. However, we believe that leveraging closed-source techniques can address this issue. For example, critical logic can be placed in a closed-source dynamic library (e.g., .dll or .so files) and invoked via Python’s ctypes module. Alternatively, the key logic could be implemented in Cython, compiled into a binary file, and called accordingly. Additionally, tools such as PyArmor can be used to encrypt or obfuscate the implementation details, ensuring the protection of the underlying logic.

Based on the above analysis, we believe it is a reasonable and achievable assumption that the trainer must execute the wrapper as-is and cannot modify it.

$\textcolor{red}{{\rm GR.5}}$ Who Generates the Key $k$?

In the manuscript, $\textcolor{green}{{\rm Figure~3}}$ illustrates only the demonstrates the principles of the framework, highlighting that a key $k$ needs to be generated during the T-Train process.

From an implementation perspective, based on the analysis above, we can see that when the security risk is low, the trainer can generate the key themselves. For instance, the verifyer provide a ${\rm KeyGen()}$ function. Each trainer is assigned a unique ID $d$, and it could excute ${\rm k \leftarrow KeyGen(d)}$, ensuring that $k$ meets specific formatting requirements.

When security risks are present (as analyzed in $\textcolor{red}{{\rm GR.4}}$ under scenarios DL-II and DL-III), we recommend that the verifier generate and control the key, ensuring it is not accessible to the trainer. This is precisely the meaning of "through a server API" mentioned in the paper ($\textcolor{green}{{\rm L485}}$). Building on the implementation methods discussed in $\textcolor{red}{{\rm GR.3.2}}$, we propose a potential implementation scheme:

---

$\textcolor{blue}{{\rm 1.Key~Initialization:}}$ The trainer first registers on the server provided by the verifier and only obtains a user ID $d$. The verifier then generate the key ${\rm k \leftarrow KeyGen(d)}$ and retains the pair $<d, k>$ exclusively on the server (verifier) side.

$\textcolor{blue}{{\rm 2.TrustedTraining~Wrapper:}}$ The trainer inputs its ID $d$ (not the key $k$) into the wrapper. The wrapper sends $d$ to the server, which returns the key $k$. The wrapper then proceeds keyed-hash and the subsequent processes.

$\textcolor{blue}{{\rm 3. Verification:}}$ The trainer submits its ID $d$ to the verifier, which then retrieves the corresponding key $k$ from the stored pair $<d, k>$ on the server and proceeds with the subsequent verification process.

---

Note that the communication process in the wrapper must also adhere to the assumptions of this work: it must not be "compromised" by the trainer. Specifically, the trainer should not be able to intercept or decrypt the key.