Secure and trusted partial grey-box verification

A crucial aspect in the development of software-intensive systems is verification. This is the process of checking whether the system has been implemented in compliance with its specification. In many situations, the manufacture of one or more components of the system is outsourced. We study the case of how a third party (the verifier) can verify an outsourced component effectively, without access to all the details of the internal design of that component built by the developer. We limit the design detail that is made available to the verifier to a diagram of interconnections between the different design units within the component, but encrypt the design details within the units and also the intermediate values passed between the design units. We formalize this notion of limited information using tabular expressions to describe the functions in both the specifications and the design. The most common form of verification is testing, and it is known that black-box testing of the component is not effective enough in deriving test cases that will adequately determine the correctness of the implementation, and the safety of its behaviour. We have developed protocols that allow for the derivation of test cases that take advantage of the design details disclosed as described above. We can regard this as partial grey-box testing that does not compromise the developer’s secret information. Our protocols work with both trusted and untrusted developers, as well as trusted and untrusted verifiers, and allow for the checking of the correctness of the verification process itself by any third party, and at any time. Currently our results are derived under the simplifying assumption that the software design units are linked acyclically. We leave the lifting of this assumption as an open problem for future research.

1. In general, the two pairs (D, R) and (\(D^{spec}, R^{spec}\)) may not be the same. Nevertheless, in this case there must be a predetermined mapping provided by the implementation designer, which converts (\(D_{spec}, R_{spec}\)) to (D, R) and vice versa, since, otherwise, the specifications verification is meaningless as a process.

Authors and Affiliations

1. Department of Computing and Software, McMaster University, 1280 Main St. West, Hamilton, ON, L8S 4K1, Canada

   Yixian Cai, George Karakostas & Alan Wassyng

Corresponding author

Correspondence to George Karakostas.

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

An example for Sect. 4

In this subsection, we use the example in Fig. 15 to show how to apply our verification scheme to actually verify a specific table graph. In Fig. 15, there is an initial table graph that is to be verified by the verifier V.

An initial table graph \(\mathcal {G}\) of an implementation

Full size image

First the developer transforms this initial table graph into a table graph G introduced in Sect. 2.2 (see Fig. 1c). Then

The developer applies our content-secure verification scheme VS to G. It runs VS.Encrypt as follows. \((G',hpk,U) \leftarrow VS.Encrypt(1^K,G)\). Figure 16 is the encrypted table graph \(G'\).

An encrypted table graph \(G'\) after applying VS to G

Full size image

According to our protocol, the verifier V receives \(G'\) and does the verification on \(G'\). We show how V can do MC/DC verification [2] on \(G'\). MC/DC performs structural coverage analysis. First it gets test cases generated from analysing a given program’s requirements. Then it checks whether these test cases actually cover the given program’s structure and finds out the part of the program’s structure which is not covered. First we assume the VGA that V uses will do MC/DC verification after it generates the test cases. Suppose V runs VGA to generate the test cases, based on requirements-based tests (by analysing \(G^{spec}\)), and these test cases are stored in EI. Then V picks an external input X to \(G'\) from EI and starts evaluating \(G'\) with X.

For \(X=(a=46,b=True)\), V sends the following queries to the developer DL (the queries are in the format of the input of VS.Encode): \(Q_1=(1,(\top ,46),null,q_1)\), \(Q_2=(2,(\top ,46),null,q_1)\), \(Q_3=(3,(\top ,46),null,q_1)\), \(Q_4=(4,(\top ,46),null,q_1)\), \(Q_5=(7,(\top ,True),null,q_1)\), \(Q_6=(8,(\top ,True),null,q_1)\), because it needs to evaluate \(PT'_1\), \(PT'_2\), \(PT'_3\), \(PT'_4\), \(PT'_7\), \(PT'_8\) as well as an encoding for the external inputs of each table. We take the evaluation of the path (Input \(\rightarrow PT'_1 \rightarrow PT'_6 \rightarrow \) Output) as an example. For query \(Q_1\), DL evaluates \(VS.Encode(Q_1)\) and returns FHE.Enc(hpk, 46)(FHE.Enc(hpk, 46) is the output of \(VS.Encode(Q_1)\)), which is the input \(x^1\) to \(PT'_1\). Then V runs \(FHE.Eval(hpk,U,x^1,E_{C_1})\) and outputs \(PT'_1(x^1)\). After this V sends \((1,x^1,PT'_1(x^1),q_2)\) to DL. Because we know that for \(PT_1 \in G\), if 46 is the input to \(PT_1\), then the output will be \((\top ,26)\). Thus for the query \((1,x^1,PT'_1(x^1),q_2)\), DL evaluates \(VS.Encode(1,x^1,PT'_1(x^1),q_2)\) and returns \(\top \). Hence, V knows that for a=46 as an external input, the lhs predicate (a decision and condition) of \(PT_1 \in G\) is satisfied, and the rhs function of \(PT_1 \in G\) is covered.

After finishing evaluating \(PT'_1\), V starts evaluating \(PT'_5\) and \(PT'_6\) with \(PT'_1(x^1)\) as their input. \(x^6=PT'_1(x^1)\) is \(PT'_6\)’s input. After finishing evaluating \(PT'_6\), V gets \(PT'_6(x^6)\) as the output. Then V sends \((6,x^6,PT'_6(x^6,q_2)\) to DL. DL evaluates \(VS.Encode(6,x^6,PT'_6(x^6,q_2)\) and VS.Encode’s output is True (Because \((26<30)\), \(PT_5\)’s output is \((\top ,False)\). We also know that the output of \(PT'_6\) is an external output. Accordingly, VS.Encode outputs False). Therefore, DL returns False to V. Then V knows that \(y1=False\) as well as the fact that the lhs predicate (a decision and condition) of \(PT_6 \in G\) is satisfied and the rhs function of \(PT_6 \in G\) is covered.

After evaluating \(G'\) with \(X=(a=46,b=True)\) by similar steps as described above and getting the external output \(Y=(\bot ,False,\bot ,2,\bot )\), V knows that for X, the lhs predicates of \(PT_1\), \(PT_6\) and \(PT_7\) are satisfied while the rest tables’ lhs predicates are not satisfied. Hence, V knows that the predicates of \(PT_1\), \(PT_6\) and \(PT_7\) are True while the predicates in the rest tables of G are False and the statements (the rhs functions of the tables in G) of \(PT_1\), \(PT_6\) and \(PT_7\) are covered. Moreover, V compares Y with \(G^{spec}(X)\) to see if G behaves as expected with X as an external input.

V will keep evaluating \(G'\) with the rest external inputs in EI, and by interacting with DL in the way as described above, it does the structural coverage analysis of the requirements-based test cases. He will be able to know whether the external inputs in EI covers every predicates in G. Additionally, it will be able to know whether G behaves as expected in the requirements specification described by \(G^{spec}\).

Reprints and permissions