Secure Collaboration in Engineering Systems Design

While online collaborations are revolutionizing design and manufacturing, they are falling short of achieving their full potential because there are significant barriers to information-sharing. These include the fear that information voluntarily shared with a partner can later be used in ways contrary to the volunteer's interests, the fear that sensitive information will leak to a competitor [1]. What a participant gains from the mutual sharing of information can be more than offset by what is lost from revealing confidential and proprietary information. There are also government regulations about information-sharing: if one of the parties is government, or if foreign entities are among the participants, then there are national security reasons to protect sensitive information. Within engineering design, such privacy concerns are the key barriers impeding collaboration [2,3], specifically, in three design scenarios: collaborative exploration of design space, crowdsourcing, and cloud-based design and manufacturing (CBDM).

During the early stages of systems design, before parties have decided whether the collaboration would be meaningful, designers generally need to exchange information about capabilities and subsystem behaviors. Such information can either be in terms of performance curves and datasheets, or test results from independent entities. For complex systems, designers may need detailed mathematical models encapsulating the behavior to ensure that the subsystem performs well within the context of the overall system. Such behavioral models embody significant knowledge and have the potential to reveal confidential information about the subsystem. In such cases, designers may be reluctant to share the models for collaborative exploration of design spaces. Existing research on collaborative engineering design has not addressed such scenarios because of the implicit assumption that collaborating entities are willing to share all the details about their part of the design. Collaborative design platforms such as the product data management (PDM) and product lifecycle management (PLM) systems are only focused on access management, i.e., a participant either has access to data/models or not. These access control approaches [4,5] are designed against malicious agents outside the collaboration. However, they are not useful against malicious or curious partners. Moreover, such an approach works well for later stages of design, after partnerships have been established, but not for the early stages of design described previously. Similarly, distributed collaborative simulation platforms such as iSIGHT, ModelCenter, and FIPER [6] also lack the capabilities to protect confidential information from prospective partners, while enabling joint simulation.

Crowdsourcing [7] is another scenario where mutually beneficial design interactions may be hampered due to concerns over security of private information. Crowdsourcing is the practice of outsourcing tasks, traditionally performed by employees or suppliers, to a large group of people in the form of open tournaments [7]. It involves two types of parties—seekers and solvers. Seekers have a problem that they want to solve, and solvers are individuals who compete to solve the problems. The solver who submits the best solution receives a prespecified award. Crowdsourcing is attractive for product development organizations because of various benefits, including access to a broad pool of solvers, increased capacity of idea generation through open innovation, and the opportunity for cost savings because the payment is made only after solutions are obtained [8]. However, the downside of crowdsourcing is that solvers may be unwilling to respond to the competition due to the fear that their ideas may be misused without a reward. Similarly, if the seeker is a defense agency, it may be unwilling to share the details of their problem in online settings for security reasons. Hence, the success of crowdsourcing as a mechanism for design collaboration significantly depends on the availability of secure collaboration in engineering design.

The third emerging scenario where secure collaboration is important is CBDM. CBDM is a product realization model that enables rapid product development through on-demand distributed system of interconnected physical and virtual design and manufacturing services [9]. The economics of using clouds for designing by services [10] are compelling due to the potential for dynamically adapting the amount of computing resources and hardware needed. However, security and privacy are some of the main factors affecting the adoption of public clouds by organizations [11]. Because of the trust issues, many organizations prefer secure and private clouds that are more expensive to develop, operate, and maintain.

As a summary, there are three main impediments to design collaboration, which have resulted in the unwillingness to (a) collaborate during design exploration, (b) participate in crowdsourcing tournaments, and (c) make use of cloud. The goal of the work presented in this paper is to make such online design collaborations possible in the codesign of engineering artifacts when participants are reluctant to share their own confidential and proprietary information with the other codesigners, even though such information is needed for producing a design of the appropriate quality and performance. Our main results are online protocols that enable the parties in the codesign to cooperatively achieve the desired result without any of them revealing their own private data, even though the jointly designed engineering artifact depends crucially on every participant's private data. We also demonstrate the viability of our protocols by implementing them and experimentally evaluating them.

Our approach does not use encryption and other cryptographic primitives, even though it is well known that techniques from the cryptographic area of secure multiparty computation [12] are perfectly capable, in theory, of solving all of the codesign problems considered in this paper. This is primarily due to performance issues. The use of cryptographic techniques would involve operations like fully homomorphic encryption [13] and secure circuit evaluation [14] that, when used in the context of the mathematical calculations for engineering design, would be both very slow and very hard to implement, which is also observed in Ref. [15]. In contrast, our protocols use the same mathematical primitives that arise anyway in the design process.

On the other hand, our approach does increase the size of the numbers involved, but the addition and multiplication of large numbers is nevertheless orders of magnitude faster than the use of the previously-mentioned cryptographic primitives. The need for using larger numbers than those in the current design process arises, because in our protocols, codesigners hide their numbers through adding and multiplying them with randoms, and it is well known that this does a good job of hiding only if the random numbers used are much larger than the numbers they are meant to hide (unless the arithmetic is modular, in which case the hiding is perfect). Using modular arithmetic (for perfect hiding) is something worth investigating in follow-on work—we have chosen to avoid it in our current design and implementation because (i) it would substantially complicate our protocols (and may even make some of them impractical) and (ii) our current use of large randoms for hiding (without modular arithmetic) does a good enough job for most practical situations. In addition to the protocols, we designed and implemented for the specific codesign scenarios we considered and our demonstration of their practical viability, another contribution of this work is that the computational building blocks we presented and used in our protocols are highly likely to be useful for other scenarios and in other contexts.

The outline of the paper is as follows: In Sec. 2, we discuss engineering design scenarios where secure collaboration can be utilized. Section 3 provides details of the protocols used for secure computation in design. A discussion of the characteristics of the protocols is provided in Sec. 4. The implementation details and results for an illustrative design scenario are presented in Sec. 5. Finally, closing comments are presented in Sec. 6.

Consider a scenario shown in Fig. 1 where two parties, Alice and Bob, own subsystems 1 and 2, respectively. They possess detailed information about the behaviors of these subsystems. Specifically, we focus on the dynamic characteristics of these subsystems, represented by state-space equations. The behaviors of the individual subsystems can be represented using matrices A_i, B_i, C_i, and D_i, and the behavior of the composed system is described using matrices A, B, C, and D. Matrices A, B, C, and D are dependent on A_i, B_i, C_i, and D_i. We assume that Alice and Bob are both interested in knowing the behavior of the composed system but are unwilling to share the details of their matrices with anyone (i.e., neither with each other nor with any third party). It is also assumed that both the parties have no incentive to lie about their individual systems properties. This is a reasonable assumption in design exploration to establish collaboration, because once the parties agree to collaborate, they will share the details of the models with each other for detailed design.

The state-space formulation of dynamical systems is chosen because (a) any dynamical system, including those with multiple inputs and multiple outputs, can be represented in terms of the state-space equations, (b) it is general enough to be applied to mechanical and nonmechanical systems, (c) nonlinear systems can be modeled by linearizing the system about the operating point, and (d) several system-level properties, such as observability, controllability, and stability, can be revealed without completely solving the state-space equations.

For privacy preservation, there are restrictions on the kinds of system-level properties which can be explored. For example, if the parties want to know the detailed responses for different types of inputs, each party may be able to extract the hidden parameters (or other related information such as bounds on parameters) just based on the responses. If the properties under investigation implicitly reveal any information about the proprietary data, the privacy constraint is violated. Hence, such properties cannot be jointly studied. However, properties which do not implicitly reveal confidential information can be investigated, and protocols for those properties may be developed. Examples of such properties include observability, controllability, Lyapunov stability, detectability, and stabilizability. In this paper, we study the first three properties. In addition to this, the protocols presented in this paper can be used to answer questions such as “does the solution enter a certain domain?” without revealing any additional information about the private data.

The level of required privacy can be categorized into two scenarios:

1. (1)

   A scenario where no single party has knowledge of the structure of the composed system, i.e., how the system-level matrices depend on the subsystem-level matrices. The parties are not willing to share the details of their respective matrices with each other or with any third party.

2. (2)

   A scenario where the mathematical structure of the composed system (i.e., how the system-level matrices depend on the subsystem level matrices) is known to at least one of the collaborating parties while the parameter values of the various components in the system are private.

In this paper, we consider linear time-invariant (LTI) systems designed under the second scenario where the structure of the collaborative system is known to at least one party with the parameter values being proprietary to the respective parties. For this scenario, we present protocols to jointly evaluate properties of the composed dynamical system.

We illustrate the protocols using a specific example of an automotive company (Alice) collaborating with a tire company (Bob). Alice has a model of the dynamics of the suspension system, which is assumed to be a moving vehicle and suspension system half-car model [16] (see Fig. 2). Bob has a model of the tires, which is assumed to be a simple spring–mass system. It is also assumed that Alice has complete knowledge of the structure of the composed system but does not know the parameter values in the tire model which are Bob's proprietary data. Such an assumption is justified for systems that are mature and their topologies are well known. In this case, the assumption is that the tire model is well known, whereas the suspension-system model may have a proprietary structure. Through the collaboration, both parties are interested in learning about controllability and observability of the codesigned system.

The models considered in this paper are simplistic compared to those used in practice, because our aim is to lay the foundational framework for such collaborations without getting distracted by the modeling details. Hence, considering a simple model is justified as it highlights the issues and how they are addressed while keeping the complexity down. The protocols presented in the paper are independent of the problem size. Hence, they can directly be used for more complex models. Also, the collaboration here involves only two parties, but upon observing the techniques employed, we see that modeling such collaborations between multiple parties is straightforward by using the protocols for multiple parties in the collaboration. This is enabled due to the nature of the protocols which can be generalized for any number of collaborating parties.

Our protocols not only preserve the privacy of the proprietary parameters of the respective parties but also ensure that the design of Alice's subsystem is not leaked. To this end, our protocols run in two stages (see Fig. 3):

1. (1)

   The additive split protocol (described in Sec. 3.2) splits the terms of the state-space matrices (A, B, C, and D) among the collaborating parties. Note that these matrices are functions of the private parameters of the respective parties and Alice has information about the structure of the overall system, i.e., how the elements of the matrices are dependent on the privately held parameters.

2. (2)

   The next set of protocols enables us to perform various mathematical operations on the obtained additively split terms. We check the full rank of the observability and controllability matrices and check for the negative definiteness of the matrix A (using protocols in Sec. 3.3).

We discuss the protocols in detail in Sec. 3.

In this section, three sets of protocols are presented. The general problem setting is that two parties Alice and Bob, denoted by A and B, both possess some private input data, and want to perform specific computations with help from a cloud server S, without leaking his/her input to the other party or to S. The server S is modeled as an honest-but-curious server, i.e., S behaves as the protocol states and does not collude with either client, but tries to learn any confidential information about the clients' input or output. Our security assumption is that adding a large random to a value hides it and multiplying a nonzero value by a large random hides it. We will discuss this in detail in Sec. 4.

Therefore, we use an additively split scheme to hide all the values involved. To additively split (or split for short) a value v into two, say v_A and v_B, a value is randomly chosen as v_A, and v_B = (v − v_A). Here, v_A and v_B are called the secret shares of v. If two parties each have one share of v, we say they additively share (or share for short) the value v. A party possessing either v_A or v_B could not infer v from that, and the statistical information they obtain is negligible if the random numbers used for hiding are much larger than the values they are used to hide (more on this in Sec. 4).

In Sec. 3.1, we present a set of needed arithmetic protocols. All the input values to the protocols are additively shared by A and B, and these protocols enable them to perform arithmetic operations and get the results also in the split form. The ingenuity of these protocols is to enable A and B to compute without allowing server to learn. A and B achieve this by morphing the additive splits (of inputs) before sending to the server. This morphing function need to have the following properties:

1. (1)

   It should be possible to recreate the morphing by both A and B.

2. (2)

   Removal of morphing should be possible on the additive splits (of computed result) received from the server.

After each protocol, we briefly show its correctness and prove that no party could learn any information other than its own input during executing the current protocol.

In most real-world applications, the inputs to the codesign system are not initially additively split and shared by the two codesigners, and moreover, the designers want to know the true result, not just a randomlike share. Therefore, to make these protocols complete, a general method is provided in Sec. 3.2 to additively split the inputs between the designers, and a protocol is presented to enable the designers to merge the output back from its split form.

With the ability to split the inputs and merge the outputs, we can solve complicated codesign problems by decomposing them into those building blocks in Sec. 3.1. Section 3.3 presents several high-level protocols to test specific properties of a matrix, which suffice to solve the problems presented in Sec. 2, just as examples of decomposing problems.

In this subsection, we present a set of protocols to achieve arithmetic computations on inputs shared by two parties A and B, without leaking one party's input to the other or to S, which is proved in their following security analysis. These protocols are building blocks for the customized high-level protocols.

A and B are able to generate the same random numbers without communication with each other. This is achieved in the setup phase by agreeing on a secret random seed and a cryptographically strong hash function. Using the same hash chain and the same initial seed, A and B generate the random numbers at their own machine. Such random numbers, known to both A and B, are called shared random numbers when presenting the protocols. All the shared random values used in the protocols should be nonzero. If a zero is generated, A and B just discard it and generate another.

Input: A value (or vector, matrix) v additively shared by A and B as v_A and v_B; and a value (or vector, matrix) u additively shared by A and B as u_A and u_B.

Output: w, additively shared by A and B as w_A and w_B, and w = v ± u. Please refer Fig. 4 for a pictorial representation of Addition and Subtraction Protocol.

Protocol:

1. (1)

   A computes w_A = v_A ± u_A.

2. (2)

   B computes w_B = v_B ± u_B.

Correctness: It can be easily verified that w = w_A + w_B = v ± u.

Security: A and B only do computation based on their own input, and thus cannot learn any information by performing this protocol.

Input: A value v additively shared by A and B as v_A and v_B; and a value u additively shared by A and B as u_A and u_B.

Output: w, additively shared by A and B as w_A and w_B, and w = vu. See Fig. 5 for a pictorial representation of the Multiplication Protocol.

Protocol:

1. (1)

   A generates four shared random numbers r₁, r₂, r₃, and r₄, and sends a pair $(r1*vA+r2,r3*uA+r4)$ to S. B generates the same shared random numbers r₁, r₂, r₃, and r₄, and sends a pair $(r1*vB−r2,r3*uB−r4)$ to S.

2. (2)

   S receives a pair from A denoted as (P_1,A, P_2,A), and a pair from B denoted as (P_1,B, P_2,B), and computes a value $t=(P1,A+P1,B)*(P2,A+P2,B)$⁠. S additively splits t into t_A and t_B, and sends them to A and B, respectively.

3. (3)

   A receives t_A, generates another shared random number r₅, and computes $wA=tA/(r1r3)+r5$⁠.

   B receives t_B, generates the same r₅, and computes $wB=tB/(r1r3)−r5$⁠.

Correctness: This can be verified as $w=wA+wB=(tA+tB)/(r1r3)=vu$⁠.

Security: From S's view, the inputs are hidden by four random values in step 2 and S cannot learn them. And, the output w is hidden from S by multiplying (r₁r₃), so S cannot learn it either. However, in step 2, S knows how it splits t, i.e., the ratio between its two shares t_A and t_B. So, in step 3, r₅ is used to get a fresh split of w so that the ratio between the two shares of w is not same as t, preventing S from knowing information about how the output is split. From A and B's view, the only values received by them are split shares of a value, which will not leak to them the result or information about how the output is split. Except these values, no party obtains additional information by executing this protocol.

Input: A value v additively shared by A and B as v_A and v_B; and a nonzero value u additively shared by A and B as u_A and u_B.

Output: w, additively shared by A and B as w_A and w_B, and w = v/u. Please refer to Fig. 6 for a pictorial representation of the Division Protocol.

Protocol:

1. (1)

   A generates four shared random numbers r₁, r₂, r₃, and r₄, and sends a pair $(vA*r1+r2,uA*r3+r4)$ to S. B generates the same shared random numbers r₁, r₂, r₃, and r₄, and sends a pair $(vB*r1−r2,uB*r3−r4)$ to S.

2. (2)

   S receives a pair from A denoted as (P_1,A, P_2,A), and a pair from B denoted as (P_1,B, P_2,B), and computes a value $q=(P1,A+P1,B)/(P2,A+P2,B)$⁠. S additively splits q into q_A and q_B, and sends them to A and B, respectively.

3. (3)

   A receives q_A, generates another shared random number r₅, and computes $wA=qA*(r3/r1)+r5$⁠.

   B receives q_B, generates the same r₅, and computes $wB=qB*(r3/r1)−r5$⁠.

Correctness: This can be verified as $w=wA+wB=q*(r3/r1)=(vA+vB)/(uA+uB)=v/u$⁠.

Security: The analysis of security is similar as the MP protocol.

Input: A value v additively shared by A and B as v_A and v_B.

Output: A complex value x_A held by A and x_B held by B, whereas $xA+xB=ln(v)$⁠. Please refer to Fig. 7 for a pictorial representation of the Logarithm protocol.

Protocol:

1. (1)

   A generates two shared random numbers r₁ and r₂, and sends $vA*r1+r2$ to S. B generates the same shared random numbers r₁ and r₂, and sends $vB*r1−r2$ to S.

2. (2)

   S receives a value from A denoted as p_A, and a value from B denoted as p_B, and computes a complex number $q=ln(pA+pB)$⁠. S additively splits q into two complex values as q_A and q_B, and sends them correspondingly to A and B.

3. (3)

   A receives q_A from S, generates a shared complex random number r₃, and computes x_A = q_A + r₃. B receives q_B from S, generates the same r₃, and computes $xB=qB−ln(r1)−r3$⁠.

Correctness: This is verified as $xA+xB=q−ln(r1)=ln(pA+pB)−ln(r1)=ln((pA+pB)/r1)=ln(v)$⁠.

Security: From S's view, the inputs are hidden by r₁ and r₂ and S cannot learn them. And, the output x is hidden from S by $ln(r1)$⁠, so S cannot learn it either. r₃ prevents S from knowing information about how the output is split by q_A and q_B. From A and B's view, the only values received by them are split shares of a value, which will not leak to them the result or information about how the output is split. Except these values, no party obtains additional information by executing this protocol.

Input: Assume that A and B mutually agree upon n which is larger than their individual inputs (v, u, respectively). Let B represents u as an array of n bits which is denoted by u. Invert every bit in u and denote this array by c. A determines two arrays of length n: $x=[v20,v21,v22,v23,…v2n−1]$ and $y=[1,1,1…1]$⁠. A and B share one of their additive splits with each other. So, A has $xA,uA,yA,cA$ and B has $xB,uB,yB,cB$ as inputs to this protocol.

Output: w_n, additively shared by A and B as w_A,n and w_B.n, and w_n = v^u.

Protocol: This protocol is split into three phases: In phase 1, A and B determine an intermediate array t = u ∘ x. Here, ∘ denotes hadamard product and the elements in the array t are given by (⁠$ti=uixi ∀i∈(1,n)$⁠). Phase 2 is very similar to phase 1. In phase 2, A and B determine an intermediate array m = y ∘ c. In phase 3, A and B add their additive splits obtained from phase 1 and 2 and determine the product of all the elements in it. This product turns out to be equal to v^u.

Phase 1

Input: A has arrays $xA,uA$ and B has $xB,uB$

Output: A and B receive $tA, tB$ from server, where $tA+tB=x°u$⁠. Note that ∘ stands for hadamard product. See Fig. 8 for a pictorial representation of Phase 1 of the Exponentiation Protocol.

Protocol: A and B perform MP protocol for all the n pairs in the two vectors and thus get n intermediate results. These results are stored in an array q. Figure 8 displays the multiplication for an ith element in x, u. By the end of n multiplications in phase 1, Alice and Bob have arrays $tA$ and $tB$⁠, respectively.

Phase 2

Input: A has arrays $yA,cA$ and B has $yB,cB$

Output: A and B receive $zA, zB$ from server, where $zA+zB=y°c$⁠. Note that ∘ stands for hadamard product. Please refer to Fig. 9 for a pictorial representation of Phase 2 of Exponentiation Protocol.

Protocol: The protocol is same as that stated in phase 1. Only the inputs are different. Figure 9 displays the multiplication of between ith elements in y, c. By the end of n multiplications in phase 2, Alice and Bob have arrays $mA$ and $mB$⁠, respectively.

Phase 3

Input: A has arrays $tA,mA$ and B has $tB,mB$

Output: A and B receive w_A,n, w_B,n from server, where w_A,n + w_B,n = v^u. See Fig. 10 for a pictorial representation of Phase 3 of the Exponentiation Protocol.

Protocol: In this phase also, we use MP protocol. However, unlike earlier, here it is recursive in nature. We multiply all the elements in the arrays t + m. Since the splits (k_A, k_B) received from server are additive in nature, we add k_A to the existing w_A,i

Input: A nonzero value v shared by A and B as v_A and v_B.

Output: A binary bit b, denoting whether v > 0, shared by A and B as two bits b_A and b_B, and $b=bA+bB mod 2$⁠. Please refer to Fig. 11 for a pictorial representation of the GT0 Protocol.

Protocol:

1. (1)

   A generates two shared random numbers r₁ and r₂, and sends p_A = v_A/r₁ + r₂ to S. B generates the same random r₁ and r₂, and sends p_B = v_B/r₁ − r₂ to S.

2. (2)

   S adds p_A and p_B, and sets a bit b as 1 if the sum is greater than zero and as 0 if not. S additively splits b into two bits $bA′$ and $bB′$⁠, and sends them to A and B, respectively.

3. (3)

   If r₁ is positive, A and B set b_A and b_B as $bA′$ and $bB′$⁠, respectively; otherwise, A sets $bA=−bA′$⁠, but B sets $bB=1−bB′$⁠.

Correctness: It is straightforward to verify this protocol works.

Security: From S's view, the inputs are hidden by r₁ and r₂, and the output bit b is perfectly hidden by the sign of r₁. A or B only sees an additive share of a bit, which will not leak any information of the output.

In the high- level protocols, A and B need to check whether some operand is zero as a branch condition in the code. For example, if a pivot is zero in the Gaussian elimination, they will call a row swap function. This protocol tells them whether the condition is true or false, without leaking the value if it is not zero, and assuming that in the setting up phase, A and B agreed a cryptographic hash function H().

Input: A value v shared by A and B as v_A and v_B.

Output: A and B learn whether v = 0 or not. See Fig. 12 for a pictorial representation of the EW0 Protocol.

Protocol:

1. (1)

   A generates a local random number r_A and computes x_A = r_A * v_A, and sends it to B. B generates a local random number r_B and computes x_B = r_B * v_B, and sends it to A.

2. (2)

   Please note that Alice is not aware of r_B and Bob is not aware of r_A.

3. (3)

   A computes y_A = x_B * r_A. B computes y_B = x_A * r_B.

4. (4)

   A computes H(−y_A), and sends it to S. B computes H(−y_B), and sends it to S.

5. (5)

   S simply sends what it receives from A to B, and what it receives from B to A.

6. (6)

   A receives the value H(−y_B) from S. If H(−y_B) = H(y_A), it learns v = 0; otherwise, it learns v ≠ 0. B receives the value H(−y_A) from S. If H(−y_A) = H(y_B), it learns v = 0; otherwise, it learns v ≠ 0.

Correctness: If v = 0, then v_A = −v_B, and thus H(y_A) = H(−y_B); otherwise, H(y_A) ≠ H(−y_B). So, A and B learn the correct answer by checking the equivalence of the hashed values. Note that, in the computer representation with rounding issues, negligible values are usually treated as zeros, and the protocol can be modified to handle such cases smoothly as follows: Before performing the protocol, A and B truncate the most insignificant bits of v_A and v_B according to error tolerance setting.

Security: Due to the one-way property of hash functions, each party cannot learn the true values by seeing the hashed values.

In the above GT0 protocol, we use noncryptographic operations to compare a number with 0, and this is secure under our assumptions, and it may leak some information under the standard security assumptions. In this section, we provide a provable secure approach using the garbled circuit (GC) technique [14]. To make it complete, we provide a brief review in Appendix of how two parties use GC to securely evaluate a function without leaking their own private inputs. And, in the following secure-GT0 protocol, we use GC in a variant scheme, involving a server as the circuit evaluator to get rid of the expensive oblivious transfer (OT) protocols.

Input: A nonzero value v shared by A and B as v_A and v_B.

Output: A binary bit b, denoting whether v > 0, shared by A and B as two bits b_A and b_B, and $b=bA+bB mod 2$⁠.

Protocol:

1. (1)

   A generates a random r₁, if r₁ > 0, A sets x = v_A, otherwise x = −v_A. B generates the same random r₁, if r₁ > 0, B sets y = v_B, otherwise y = −v_B.

2. (2)

   A constructs a garbled circuit C, with x and y as inputs and a bit wire denoting whether (x + y) > 0 as output. A sends C to S and tells S which input wires representing x and which representing y. A shares with B the encodings chosen for the input wires corresponding to y, and shares the encodings chosen for the output wire with S.

3. (3)

   A chooses the encodings representing x and sends them to S. B chooses the encodings representing y and sends them to S.

4. (4)

   S receives the encodings for all the input wires, then evaluates C gate by gate, and gets the encoding of the output wire. S translates the output encoding into a binary bit b, and additively splits b into two bits $bA′$ and $bB′$⁠, and sends them to A and B, respectively.

5. (5)

   If r₁ is positive, A and B set b_A and b_B as $bA′$ and $bB′$⁠, respectively; otherwise, A sets $bA=bA′$⁠, but B sets $bB=1−bB′$⁠.

We assume the inputs to the codesign systems are matrices without loss of generalization, since single values and vectors are matrices with special dimensions. Each entry in the input matrices may be depending on (1) only A's design, i.e., A's private input, (2) only B's design, i.e., B's private input, (3) both A and B's design, and (4) only some constants or public information (like the laws of physics). We distinguish these four cases for any entry x, and present how A and B get the additive splitting form of it as x_A and x_B without leaking their private input.

1. (1)

   A computes x using its own input, generates a random r using the random seed known to B, and sets x_A = x − r. B generates the same random r and sets x_B = r.

2. (2)

   A and B just switch the roles in case (1).

3. (3)

   Assume x depends on a set of A's private inputs I_A and a set of B's private inputs I_B. First, A and B additive split the input values in I_A and I_B as in (1) and (2), and then, they run the arithmetic protocols in Sec. 3.1 so that they learn x in its additively split form.

4. (4)

   A computes x only using these public information, generates a random r using the random seed known to B, and sets x_A = x − r.

B generates the same random r and sets x_B = r.

(Security) In case (1), (2), and (4), A and B do not communicate with others and thus do not learn any more information than what can be inferred from their own private input. In (3), they only communicate with the server S when performing the protocols in Sec. 3.1, which are already proved against information leaking.

Similarly, assuming the outputting result of the system is also a matrix. Each value y in it is shared by A and B as y_A and y_B after executing the protocols. Now, we present the protocol enabling A and B to learn the final result without leaking to S.

1. (1)

   A generates two shared random r₁ and r₂, and sends S y_A + r₁. B generates the same r₁ and r₂, and sends S y_B + r₂.

2. (2)

   S simple sends what it receives from A to B, and what it receives from B to A.

3. (3)

   A receives a value p_A from S and computes y = p_A + y_A − r₂. B receives a value p_B from S and computes y = p_B + y_B − r₁.

Based on the arithmetic building blocks, one can build higher level protocols to solve specific problems as stated in Sec. 2.

Input: A vector v of length n additively shared by A and B as $vA$ and $vB$⁠; and a vector u of the same length additively shared by A and B as $uA$ and $uB$⁠.

Output: w, additively shared by A and B as w_A and w_B, and w = (v, u).

Protocol:

1. (1)

   A and B perform the MP protocol for all the n pairs of aligned values in the two vectors and thus get n intermediate results.

2. (2)

   A and B perform the ASP protocol to sum these intermediate results to get w.

Input: A vector v of length n additively shared by A and B as $vA$ and $vB$

Output: A and B know whether v is a zero vector.

Protocol:

1. (1)

   A generates a random vector r_A of length n, B generates a random vector $rB$ of the same length, and they view them as an additive split of a vector r.

2. (2)

   A and B perform the VIP protocol with r and v as the inputs, result denoted as w.

3. (3)

   A and B perform the EW0 protocol with w as the input. If w = 0, they know v is a zero vector, otherwise it is not.

It is with negligible probability that w = 0, while v is nonzero.

Input: A matrix M₁ shared by A and B as M_1A and M_1B; and a matrix M₂ shared by A and B as M_2A and M_2B;

Output: M, additively shared by A and B as M_A and M_B, and M = M₁M₂.

Protocol:

For each entry m_ij in M, A and B perform a VIP protocol inputting the ith row of M₁ and the jth column of M₂, and fill the results into M_A and M_B, respectively.

Input: A matrix M shared by A and B as M_A and M_B;

Output: A and B learn whether M is of full rank or not.

We use Gaussian elimination (row reduction) to check whether a matrix is of full rank. The elimination process involves three basic elementary operations, listed with its implementation on shared data as follows.

1. (1)

   Multiplying a row with a nonzero number.

   This operation can be achieved by performing a set of MP protocols.

2. (2)

   Multiplying a row with a nonzero number and adding the result to another row.

   This operation can be achieved by performing a set of MP protocols and an ASP protocol.

3. (3)

   Interchanging two rows if a specific entry is 0.

   This operation can be achieved by interchanging the corresponding rows in both M_A and M_B, if A and B find the entry is 0 by performing the EW0 protocol.

During the elimination, A and B check whether the current processing row is a zero vector by the CVZ protocol. If they find a zero vector, then M is not of full rank.

Let M be an n × n symmetric matrix, and let M_k denote the k × k submatrix formed by deleting the last n − k rows and columns of M. The following two conditions are equivalent: (1) all the eigenvalues of M are negative, and (2) the determinants $(−1)kdet(Mk)>0$ for 1 ≤ k ≤ n, i.e., $det(M1)<0, det(M2)>0, det(M3)<0, …, (−1)ndet(Mn)=(−1)ndet(M)>0$⁠. So, to check whether the eigenvalues of a shared matrix are all negative, A and B first compute $(−1)kdet(Mk)$ for all M_k, and then compare these values with 0 with the GT0 protocol.

By this formula, $det(M)$ can be eventually reduced to the sum of products of entries from M, so A and B can compute it by performing the ASP and MP protocols in the corresponding order.

In the security proof of the protocols, it is assumed that adding a large random number to a value hides it and multiplying a nonzero value by a large random number hides it. If the random number is generated from the infinite real range (−∞, ∞), it hides the value perfectly, since the sum or product of the value and such a random is uniformly distributed over the real range. However, in the machine world, depending on the number of bits used in representation, there is a range for the random numbers, say [−b, b]. Also, there is a range for the values A and B are trying to hide, say [−t, t]. If S knows these two ranges and gets a number near the bound (b + t) as the sum of the value and a random, then it knows the value is near t. In order to prevent such leakage, A and B could either make b much larger than t so that it is not likely to generate randoms too close to the bound comparing with t, or let b vary when generating the random numbers and keep b secret from S. And, we can see that the larger b is, the better it hides, while it costs more central processing unit (CPU) time to compute.

During the running of the system, there is no need to build network connections between A and B, since our protocols do not require any interaction or data transfer between them. Therefore, this is a typical single-server-multiple-clients framework, and this model places light overhead on the client side, and the server is the only party responsible for listening to the communication socket. Moreover, this framework is easy to implement with standard network libraries.

All of those building block protocols only require a small constant round of client-server interactions, which is a desirable property for efficient network protocols. And, in the higher level protocols, the building blocks can be executed in parallel to decrease the communication rounds. For example, in the VIP protocol, there is no dependence between the n times executions of the MP protocol, so A and B can send all the values that need to be sent in the n MP executions to S at once and get back the returned values from S in one interaction round.

Figure 13 represents the flow of the protocols used to measure the different properties of the collaborative system stated in Sec. 2.1. The implementation of the various protocols was carried out sequentially in the order shown.

We implemented the code for the protocols in C++ language under MS visual studio. All the protocols are run in a single thread mode. Three separate projects were built to simulate the roles of Alice, Bob, and the server, and the server–client communication is implemented using the transmission control protocol (TCP).

We first simulate the projects as three separate processes locally on a machine with Windows OS, CPU Intel i3 core 2.40 GHz, 6 GB memory. The result is shown as follows.

As in Ref. [16], Alice's inputs are set as follow: M = 4200, K_fs = 120, K_rs = 180, B_f = 25, B_r = 35, I = 40,000, L_f = 55, and L_r = 65; Bob's inputs are set as follow: M_f = 125, M_r = 125, K_ft = 1100, and K_rt = 1100.

1. (1)

   The run time for additive splitting the matrices A, B, and C and obtaining the observability and controllability matrices at Alice's side was 6054 ms and at Bob's side was 138 ms. The reason for such a difference is mainly because Bob's code runs after the connection is built between Alice and the server. Also, Alice needs to do local computations for obtaining the additive splits as she has the knowledge of the structure of the collaborative system. Bob only has to input his private data following the protocols.

2. (2)

   The run time for checking the rank of the controllability matrix was 28 ms on both clients' ends. This collaborative system was controllable according to the output of the MFRC protocol.

3. (3)

   The run time for checking the rank of the observability matrix was 45 ms on both clients' ends. This system was observable according to the output of the MFRC protocol.

4. (4)

   The run time for checking the negative definiteness of matrix A was 44 ms on both clients' ends. This system was not stable according to the output of the MNDC protocol.

To evaluate the performance over the Internet, we planted the server on one machine, and run Alice and Bob's code on another. Note that putting the two clients on the same machine or not does not make much difference to the performance, because the network communication is only between the server and a client, and our model does not assume Alice and Bob communicates directly. We measured the running time in two scenarios: (1) the server and clients are in the same campus, the server has fast cabled network, and the clients have fair wireless Internet connections; and (2) the server is physically a remote one in China, and the clients are in the U.S. The running time of Alice is described in Table 1, and Bob is almost the same since most of the protocols are symmetric.

From the result, we can see that the network delay is significant for the protocols, and this could be improved if we reduce the communication rounds of higher level protocols. As pointed out before, instead of calling the multiplication protocol n times in the VIP protocol, the clients can send to the server all the values to be sent in these n executions in one round. As a demo implementation, this optimization was not included in the experiment.

The primary contributions of this paper within the field of engineering design are as follows: (a) formulation of the codesign problem in a form that allows secure privacy preserving simulation of system behavior, (b) new protocols for the specific codesign scenarios discussed in the paper, and (c) demonstration of the practical viability of the protocols using a collaborative design example. One of the advantages of the protocols developed in this paper is that the cloud is not used as a repository. Data are exchanged with the cloud server for computations only. From the data exchanged, the server on its own (i.e., without colluding with any of the parties) cannot infer anything about the system properties or behavior. The paper also contributes to the cryptography literature. The computational building blocks presented in this paper and used in the protocols are highly likely to be useful for other scenarios and in other contexts beyond collaborative design.

We believe that this is a modest, but encouraging, initial step toward secure, privacy preserving model-based systems engineering (MBSE) and design. One of the assumptions in the codesign scenario chosen is that one of the parties knows the complete mathematical structure of the system, and only parameter values are private. There is significant opportunity to develop protocols for other codesign scenarios where this assumption may not hold. Finally, as highlighted in Sec. 1, our approach does not use encryption and other cryptographic primitives in order to reduce computation time. The use of modular arithmetic (for perfect hiding) will be investigated in the future work.

Portions of this work were supported by National Science Foundation Grant Nos. CPS-1329979, CNS-0915436, CMMI-1265622, Science and Technology Center CCF-0939370; by an NPRP grant from the Qatar National Research Fund; and by sponsors of the Center for Education and Research in Information Assurance and Security. The statements made herein are solely the responsibility of the authors.

The basic idea to securely evaluate a function f(x, y) by the GC protocol, where x and y are the private inputs from two parties, is to (1) construct the function f as a boolean circuit C, (2) encode x and y in their binary form as the input and the function value as the output, and (3) provide a method of computing such a circuit gate by gate in such a way that values obtained on all wires other than circuit-output wires are not revealed. To hide the values, for every wire in the circuit, two random encoding values are specified such that one value represents 0 and the other represents 1. Let w denote a wire, we use w₀ and w₁ to denote the two random encoding values chosen to represent 0 and 1, respectively.

Let g be a gate with incoming wires u and v and output wire w. Now, we present how the gate g is garbled (i.e., to hide the true bit value of each wire by its random encoding value while still enabling the evaluation of the gate's output). This is accomplished by viewing the four possible input encoding values to the gate u₀, u₁, v₀, and v₁ as encryption keys, and the two possible output encoding values w₀ and w₁ which are also keys and are encrypted under the appropriate keys from the incoming wires. For example, let g be an AND gate. Then, the key w₀ is encrypted under the pairs of keys (u₀, v₀), (u₁, v₀), (u₀, v₁), and the key w₁ is encrypted under the pair of keys (u₁, v₁). So, the gate g is garbled and represented as four ciphertexts $Eu0(Ev0(w0)),Eu0(Ev1(w0)),Eu1(Ev0(w0)),Eu1(Ev1(w1))$⁠. Note that the four ciphertexts should be randomly permuted so that the position does not leak the meaning of the encoding values of wires. Now given the encoding values of the two incoming wires of a gate, one can, without knowing the meaning of input wires (i.e., whether it's 0 or 1) and the meaning of the gate (i.e., whether it's a logic AND or OR), try to decrypt the four ciphertexts, and only one will success and thus provide the proper encoding value of the output wire (we assume an “indicator of success” string of a predetermined length is appended to each plaintext). By induction, given the appropriate encoding values of all the input wires to the whole circuit, one can compute the encodings values for the output wires gate by gate without knowing the meaning of the encodings.

In a garbled circuit protocol, one party P₁ (the circuit generator) prepares a circuit for computing f, chooses two encoding values randomly for each wire, and garbles all the gates as described. P₁ sends the garbled circuit to the second party P₂ (the circuit evaluator) to evaluate. P₂ obtains the encoding value for each input bit as follows: for those input wires corresponding to P₁'s input, P₂ asks P₁ for the encoding values of them; and for the input wires corresponding to P₂'s input, the two parties use oblivious transfer (OT) to enable P₂ to obtain the encoding values without leaking his input to P₁. An OT protocol [18] allows a sender holding encoding values w₀ and w₁, to transfer to a receiver holding a selection bit b in a way that the receiver learns nothing about w_1−b, and the sender learns nothing about b. With the encoding value of each input wire, P₂ then obliviously computes the output of the circuit without learning any intermediate values. For each output wire corresponding to P₂'s output, P₁ sends both encoding values for 0 and 1, respectively to P₂ so that P₂ could interpret its own output; while for each wire corresponding to P₁'s output, P₂ just sends the output encoding value to P₁, and P₁ could interpret, since it knows the meaning of all the encodings.