Securing Graph Neural Networks in MLaaS:
A Comprehensive Realization of Query-based Integrity Verification

Node Classification via GNNs. Graph Neural Networks demonstrate great success in graph analysis tasks. In this paper, we consider a basic yet widely adopted GNN task, i.e., node classification. A node classification GNN aims to label the nodes based on both the structure and attributes of the nodes in the graph. Generally, GNN for node classification has two different learning settings: transductive setting and inductive setting. In the former setting, a training and inference graph is used to train a GNN model. Namely, the training graph is also used for inference. In practice, this setting occurs when a graph has partially labeled nodes, and GNN is used to predict the label for the rest of the nodes. For the latter setting, the training graph of the GNN model is different from the inference graph. This setting is similar to the traditional learning settings where GNN learns the knowledge from a training graph and is used to predict the label of other unseen graph data.

Machine Learning as a Service for GNNs. Machine Learning as a Service (MLaaS) is trending as an emerging cloud service for training and serving of machine learning models. It enables model owners to build (Training Service) and deploy (Serving Service) their model and learning applications to model users conveniently and automatically. A notable example is the SageMaker framework provided by Amazon, which has integrated a popular graph learning tool (i.e. DGL [41]) for the development and deployment of GNNs [42]. In this paper, we focus on the Serving Service, and consider that model owners first upload their locally trained GNN model to the cloud storage or specify the location of an online GNN model. Then, they create and configure the Hosting Service with an HTTPS endpoint. The Hosting Service will create a serving instance that loads the GNN model from the cloud storage bucket and launches the endpoint to host the model prediction. This endpoint is persistent and will remain active, so model users can make instantaneous prediction queries at any time.

Attack Surfaces. As an emerging service launched by public cloud service providers, MLaaS naturally faces the same threats of cloud computing, such as misconfiguration [23, 24], insufficient identity and access management [43, 44], insider threat [45, 46], insecure interfaces and APIs [47, 48]. We deem that these long-standing threats create practical attack surfaces for adversarial perturbations over GNN models. For example, MLaaS stores the GNN models in cloud storage, which has been demonstrated with large attack surfaces [38, 49, 50]. Specifically, an AWS S3 bucket can be accessed and overwritten by unauthorized users due to misconfigurations [33, 36] or exploited by an internal malicious user [34, 35]. Such issues allow attackers to manipulate GNN models before being loaded by the inference instance of MLaaS.

Attack Coverage. In this paper, we discuss two practical model-centric attacks compromising GNN model integrity.

- Fault Injections to Model Parameters. The attacker injects faults into a few bits of the GNN model parameter and forces the model to misclassify the nodes, also known as Bit-flip Attacks (BFAs) [20, 21, 22]. Specifically, attackers can identify the most vulnerable bits among the model parameters and modify only a few of them, but significantly impacting GNN predictions. BFAs are practical considerations in MLaaS systems that store the ML model in their cloud storage (e.g., Amazon SageMaker store GNNs in S3 bucket [11]), and could be exploited using various mature attack methods, such as RowHammer [22, 51], VFS [52], and clock glitching [53]. We provide a detailed construction of BFAs on GNNs in Appendix A.1, as existing DFAs target on DNNs.

- Model Replacement by Poisoned Models. Apart from only modifying a few bits, we assume another attacker who can replace the entire model with a pre-constructed poisoned one [54, 55]. Specifically, we consider that the replaced models are generated through poisoning attacks, which is one of the well-studied adversarial attacks targeting GNN models and has been shown to cause severe mispredictions during GNN inference [54, 55]. Model replacement is also a practical concern because ML models are stored in cloud storage. Attackers could replace models before they are loaded into the MLaaS serving instance due to well-known issues in cloud storage, such as misconfigurations [33, 36] and insecure APIs [47, 48]. We formalize poisoning attacks in Appendix A.2.

Remark. There may exist other types of threats which are out of scope in this work. For example, rather than targeting the serving services, the attacker attempts to compromise the MLaaS training services. Note that model-centric attacks targeting GNN models during the training phase can be trivially verified by downloading and validating the learned model on the local side. In addition, we do not focus on data-centric attacks that compromise graph data integrity in this work, as they can be mitigated by well-studied orthogonal methods. For example, poisoning/backdoor attacks can be addressed by robust training, i.e., introducing an attention mechanism to identify adversarial perturbations and decrease their weights during the aggregation process [56]. Similarly, evasion attacks can be mitigated through adversarial training [57, 58], which makes the GNN still produce correct predictions even when the input inference graphs have been manipulated adversarially.

Verifier’s Knowledge of the GNN model. The verifier can have different knowledge of the targeted GNN model before being deployed. In practice we consider the following two cases.

- Full Knowledge to the Targeted GNN Model. In this case, the verifier has full knowledge of the GNN model, including the model parameter, model architecture, the gradient, and the internal representation for any local predictions before it is deployed in MLaaS. In practice, this verifier can be the model owner who wants to protect their model, or an entity fully authorized by the owner.

- Limited Knowledge to the Targeted GNN Model. In this case, the verifier does not have access to the GNN parameters and can only query the target GNN model and obtain the response. Nevertheless, the model owner is willing to support verification, and provide limited knowledge, e.g., node embeddings and prediction posteriors generated by the model inference. In practice, the verifier can be a third-party service, and the model owner does not want to share their well-trained model (IP of the owner) directly.

Verifier’s Knowledge of the Inference Graph. In addition to the verifier’s access to the target GNN models, we further assume the verifier’s knowledge corresponding to the inference graph of the targeted GNN to facilitate verification. We also present this in the context of both transductive and inductive settings.

- Transductive Setting. In this setting, the verifier is provided with a small set of nodes and their neighboring subgraph within the inference (also training) graph. The intuition is that training data are often considered private data of the model owner, so they prefer to provide only a limited amount of their training graph to the verifier. In practice, the owner may designate a small subset of nodes specifically for security purposes, e.g., setting some nodes in a network graph as security appliances to mitigate security threats [59]. Note that if the verifier is the model owner, they will not be constrained.

- Inductive Setting. In this setting, the verifier knows the prediction task of the targeted GNNs and can gather shadow graph data corresponding to this task. The verifier gains full access to these shadow graphs and can use them for querying. This is a common and practical assumption considered in previous work [60, 61]. For example, the shadow graph could be an earlier version of the training graph provided by the model owner, or a graph that shares similar characteristics with the target GNN task [60].

Verifier’s Access to the Deployed GNN Models. After the targeted GNN model is deployed, we assume that the verifier can access only the prediction APIs as the normal GNN model users. We deem that this is a practical setting due to security and cost-effective considerations. Only leveraging prediction APIs will make the verifier hard to be detected and bypassed, and will also not introduce additional development and implementation overhead at MLaaS.

- Queries to the Prediction APIs. The GNN prediction APIs support different formats of prediction queries depending on the GNN learning settings for node classification, i.e., transductive setting and inductive setting. 1) Transductive Setting. In this setting, the queries sent by the verifier consist only of the node ID. Since the training and inference graph is used to train the targeted GNN, the graph will not be modified during model serving. Specifically, the model owner uploads their GNN model and the training graph (aka the inference graph for predictions) to the cloud when they create the serving instance. During the serving period, users can directly issue the node ID for the serving instance to perform inference in the training graph, and respond to a corresponding label to that node. 2) Inductive Setting. In this setting, queries sent by the verifier consist of both the node ID and the graph used for inference. Differently from the transductive setting, the graphs used for inductive GNNs’ training and inference are different. Therefore, MLaaS provides APIs for users to query their inference graph during serving. Specifically, the model owner uploads only their GNN model to the cloud when creating the serving instance. During the serving period, users upload their inference graph and its node IDs for predictions. The serving instance then performs inference in the inference graph, and responds to the corresponding labels of the node IDs, respectively.

- Responses from the Prediction APIs. We assume that the prediction APIs only respond to the users with the final prediction label. In MLaaS applications, predicting the label is the most basic function provided by the prediction APIs. Therefore, this is the strictest setting for the verifier, which provides the minimum information about the model inference. It is also consistent with recent work on machine learning security [62, 61]. We are aware that, if the response is the confidence vector, the verifier can easily verify the integrity by issuing a query and comparing it to the pre-recorded confidence vector. If the confidence scores do not match, the GNN model can be considered modified.

Transductive Setting. In this setting, rather than greedily selecting fingerprint nodes among all possible verification nodes, we first randomly select several nodes as the candidates. From these candidates, we select the final fingerprint nodes according to the methods we introduced above. Note that we conduct our fingerprint node search after random sampling. This not only reduces the computation cost of our search algorithm, but also makes it more difficult for attackers to identify the fingerprint nodes. Generally, if the fingerprint nodes are first searched and then sampled, the attackers can always bypass verification by increasing the size of their potential fingerprint node set up to the total number of the sampled candidates. Nevertheless, in our proposed method, they need a much larger set of candidate nodes to ensure that the true fingerprint nodes are included. Formally, we present Theorem 1 and perform a theoretical security analysis to prove it in Appendix B.2.

Inductive Setting. For this setting, we propose to replace the fixed node label in Eq. 8 with a randomly selected label and propose to minimize the prediction loss as:

where $R(Y_{i})$ is a function that generates a random index of ${Y_{i}}$, where $Y_{i}$ is the label sets of the target graph. In Eq. 10, rather than misclassifying the fingerprint node to a fixed label, our optimization problem will misclassify it to a randomly selected label. Thus, randomness is introduced to our optimization process by forcing convergence via a randomly selected trajectory. Consequently, the verifier will produce different fingerprint nodes and increase the difficulty of the attacker bypassing our verification. Similarly, we present Theorem 2 for the security guarantee in an inductive setting.

Other Benefits. While being robust in dealing with an advanced attacker, our enhanced designs also satisfy the other two design goals: efficient and platform-independent. Both of them introduce randomness before applying our ordinary algorithm, thus, they will introduce marginal effort. Meanwhile, all these processes can be done on the verifier side only. Because they are platform-independent, it is possible for verifiers to readily update their previous verification mechanisms to the enhanced ones even after the GNN models are deployed. Namely, the GNN developer can directly ask the verifier to regenerate the randomized fingerprints without any upgradation on the server side.

Datasets and Models. Four public datasets are utilized to evaluate the proposed attack and verification methods, namely Cora, Citeseer, Pubmed [1], and Polblog [64]. These datasets serve as benchmark standards and are extensively used in the assessment of node classification GNNs. Cora, Citeseer, and Pubmed are citation networks in which nodes represent publications and the edges correspond to their citations. Each node in these networks includes attributes (i.e., keywords from the associated publication). In contrast, Polblog is a blog dataset, where each node represents a political blog, and the edges denote links between the blogs. Unlike the other datasets, Polblog does not include any attributes associated with its nodes.

Attack Coverage. Two types of attacks, BFAs and Poisoning attacks (as introduced in Section 2.2) are used to evaluate our design.

- BFAs. To evaluate how our design can detect the adversarial perturbation caused by the fault injections to the GNN model parameters, we implement Bit-flip Attacks to the GNN models by following existing attacks in DNNs [20, 65]. Specifically, we consider three types of bit flipping: BFA, where an attacker will manipulate one randomly selected parameter among the models and flip the most significant bit of the exponent part; BFA-L, where the attacker tampers with the bias of the last layer of GNNs; BFA-F, where the attacker tampers with the bias of the first layer of GNNs. Detailed settings and attack results can be found in the Appendix A.1.

- Poisoning Attacks. We also apply poisoning attacks on GNNs to evaluate our design when verifying the GNN model replaced by a poisoned model generated via adversarial attacks. Our evaluation will consider two representative attacks: Mettack [66] and a Random attack as a baseline attack that randomly adds edges to perturb the training graph to produce an adversarial GNN model. We include a detailed introduction of the poisoning attack in Appendix A.2.

Baselines. In our study, we evaluate both transductive and inductive settings of GNNs and consider two baseline designs for each setting.

- Transductive Baselines. In the transductive setting, the verification queries consist only of node IDs. We adopt the sensitive sample selection technique MANC from [63] as the first baseline. MANC aims to identify samples that activate the most neurons in the target machine learning model and utilize them for verification. Second, we introduce the Random Node Selection method as a baseline, where the verifier randomly selects nodes within the target graph and issues queries for verification. This approach represents the most fundamental baseline design for comparison.

- Inductive Baselines. In the case of inductive GNNs, the verification queries include an inference graph. We first adapt the fingerprinting generation method, sensitive-sample (denoted as SS), for DNNs from [63] to GNNs. This method commences with the generation of a single sensitive sample using a gradient-based algorithm on specific nodes’ attributes, followed by the application of the MANC sample selection method to choose multiple samples for verification. In addition, we also introduce the Ordinary Inference Graph method as a baseline, where the verifier randomly queries nodes from an inference graph in the same domain as the target GNNs’ prediction task for verification purposes.

Evaluation Metrics. To evaluate our methods, we focus on the performance corresponding to our design goals.

- Effectiveness. To demonstrate how our design can successfully detect different types of adversaries, we first define a successful detection as, when sending queries from $n$ fingerprint nodes, there exists at least one node whose label prediction from the response is different from its recorded label generated from the intact GNN. Then, we define the Detection Rate (DR) as the percentage of launched attacks successfully detected by our verification methods. For example, for BFAs, we first generate node fingerprinting pairs, repeat the BFAs $400$ times, and gather the number of attacks that successfully deduct the model accuracy of more than $5\%$. Then, we use our verification methods to detect these attacks. DR is calculated by:

- Efficiency. To demonstrate the efficiency of our design, we will show that our method only requires a small set of node fingerprints. To further substantiate the efficiency of our design, we compare our approach with the baselines and introduce a metric called Query Number Improvement (QI) to evaluate the improvement in our design over the baseline. Specifically, we use $\textit{QI}_{(A,B)}$ to represent the improvement in the number of queries from verification method A to method B when both methods are capable of achieving a detection rate $100\%$. QI is calculated as follows:

We also assess the cost of deploying our design by evaluating how seamlessly it can be integrated into MLaaS. This assessment includes considering the number of lines of code required for implementation across different entities, as well as the time cost associated with deploying our design.

- Robustness. To demonstrate the effectiveness of our enhanced designs against adaptive attacks, we define the Bypass Rate (BR) to assess how adaptive attackers can identify our verification to bypass it. BR is calculated by:

- Platform-independence. We evaluate this goal of our design by reporting both the deployment cost of our methods on the verifier side and the MLaaS side. We show that, since there is no additional cost on the MLaaS side, our design is applicable to arbitrary types of MLaaS. Namely, our design can be readily applied to different MLaaS platforms.

Transductive Settings. We begin by evaluating our verification for Transductive-F. Our initial comparison focuses on the Detection Rate (DR) under a single verification query to demonstrate the effectiveness of our fingerprinting node selection. Table III presents a comparison among our design and two baselines in four datasets against five different attacks. The results indicate that our design generally achieves higher performance than the baselines in the majority of cases, while attaining similar performance in the remaining scenarios. It could also be found that MANC also achieves substantial performance in the Citeseer dataset. This outcome is attributed to the fact that this dataset contains approximately 2 to 7 times more node attributes (around 3700) than other datasets (about 500-1400). Therefore, simply considering node attributes is sufficient for verification in this context. However, for graph datasets with fewer attributes, this design approach becomes less effective. In practice, graph data may not always possess a large number of node attributes, as they are primarily utilized to represent relationships between items (e.g., the Polblog dataset does not have node attributes). Consequently, there is a need for our design, which thoughtfully considers the graph structure when formulating the verification queries.

Inductive Settings. We next evaluate the effectiveness of our design under inductive settings. Tables V and VI present the Detection Rate (DR) for a single verification query for both the Inductive-F and Inductive-L settings. They compare our design with a baseline that queries an ordinary inference graph without modifications, as well as the sensitive sample generation method described in [63]. It should be noted that in the Inductive-F scenario, where the verifier lacks access to the target GNN models, the sensitive sample generation method cannot be employed. Moreover, since this method only takes into account the query samples’ attributes (i.e., node attributes), it is also not applicable for graph datasets without node attributes such as Polblog.

Query Efficiency. Tables VII and VIII present the QI for our design, in comparison with two baseline approaches: Random Node Selection under the transductive setting, and Ordinary Inference Graph under the inductive setting. Our design consistently outperforms these baselines across all settings and shows superior performance specifically in inductive settings. This corresponds to the effectiveness analysis in Section 6.2, which illustrates that the construction of a fingerprinting graph by altering the graph structure and node attributes of an ordinary inference graph can be highly effective for verification.

It is also worth noting that even slight improvements over the baseline are significant in practice. This is because, in real-world applications, reducing the query number is more vital in GNNs than in DNNs. As discussed in Section 3.2, unlike DNNs where users may issue numerous queries, the nodes initiating queries in GNNs could represent physical entities in a real-world graph (e.g., security appliances in a network graph provided by the system developer to mitigate threats). Therefore, minimizing the number of queries becomes essential, accentuating the practical importance of our design in the context of GNNs.

Development Cost. We then evaluate the time cost of our verification. Since our design can be accomplished by issuing inference queries from the fingerprinting nodes in the same manner as inference queries from normal users, the time cost of the queries for our verification is the same as inference queries. Namely, our verification does not incur any overhead on the server side. Similarly, on the verifier side, issuing a verification query will also take the same amount of time as a normal prediction query. The majority of the time costs come from the generation of the fingerprinting nodes. Table IX shows the time cost of generating one fingerprinting node using both our methods in three datasets. All results are recorded when our verification mechanism is running in CPU mode since we assume that the verifier who uses the MLaaS may not have high-performance computation devices such as the GPU. Considering that most of our detection requires only a small number of nodes (less than $10$), our fingerprinting node generation methods can be efficient, especially in the transductive setting.