Encrypted polynomial control based on tailored two‐party computation

Encrypted control enables confidential controller evaluations in cloud‐based or networked control systems. Roughly speaking, an encrypted controller is a modified control algorithms that is capable of computing encrypted control actions based on encrypted system states. Encrypted control has been realized using different tools from cryptography such as homomorphic encryption, secret sharing, and multiparty computation. However, the vast majority of existing encrypted controllers is linear or makes intensive use of encrypted linear operations. In this article, we present a novel and flexible method for the encrypted implementation of arbitrary polynomial controllers. Technically, our approach builds on tailored two‐party computation combined with secret sharing and additively homomorphic encryption.

F I G U R E 1 Illustration of two cloud-based control schemes with different security levels. Left: Encrypted communications but insecure controller evaluation with plaintext data. Right: Encrypted communications and encrypted controller evaluation can be distinguished. 4 Second, interdisciplinary solutions are required to secure control systems. In fact, standard information-theoretic or cryptographic tools on their own are often not sufficient (see, eg, [3, sect. 3] or 7). Most existing works focus on the integrity and availability of networked control schemes using various defense mechanisms. For example, control-related concepts such as detectability and identifiability of deception attacks are investigated in Reference 4 and game-theoretic approaches to deal with DoS attacks are, for example, considered in References 8,9. By contrast, we here focus on methods guaranteeing confidentiality (or privacy) of sensitive data in networked control systems.
A promising approach to secure the confidentiality of sensitive system states or control actions is encrypted control. The leading idea is shown in Figure 1 for a cloud-based control scheme. As apparent from the right illustration, encrypted control is realized by modifying conventional control schemes such that they are capable of computing encrypted inputs based on encrypted states without intermediate decryptions. In this context, it is important to note that encrypted control goes beyond secure communication channels (as on the left in Figure 1) that can, for example, be realized using classical symmetric encryption such as the advanced encryption standard (AES). In fact, encrypted control additionally provides security against curious cloud providers that, during controller evaluations, would have access to unsecured data for solely secured communications. The consideration of so-called honest-but-curious (or semihonest) clouds, that reliably evaluate uploaded algorithms but that are interested in the processed data, is also the key difference to existing control schemes focusing on confidentiality such as References 10,11. Encrypted control has first been realized in Reference 12 for linear state feedback. In the meantime, a few dozens of articles presented more efficient implementations and encrypted realizations of more complex control schemes (see, eg, . The different approaches can be classified based on the controller type, the system architecture, and the applied cryptographic techniques. For example, improved linear schemes have been proposed in References 14,20,22 whereas encrypted model predictive control (MPC) has been addressed in References 15,16. The articles 14,15,20 consider a single cloud whereas two (noncolluding) clouds are utilized in References 16,22 (cf. Figure 2). Finally, References 12,14,15 apply homomorphic encryption whereas 16,22 mainly build on secret sharing and multiparty computation (see Sect. 2 for a brief summary of these cryptosystems). Interestingly, although nonlinear control schemes such as MPC have been considered, the vast majority of existing encrypted controllers still builds on secure linear operations. One of a few exceptions is Reference 19, where encrypted linear-quadratic Gaussian (LQG) control is realized using labeled homomorphic encryption that supports the secure evaluation of low-degree polynomials based on a tailored multiparty scheme.
In this article, we likewise focus on the encrypted evaluation of polynomials. However, in contrast to Reference 19, we present a flexible approach that is capable of implementing arbitrary polynomial control schemes beyond (fully encrypted) LQG. We note, in this context, that polynomial control (for polynomial systems) has a long tradition in control theory. We refer the interested reader to References 23-26 for a broad overview. Polynomial controllers form an interesting class for encrypted control since they can be expressed based on a finite number of multiplications and additions. We exploit this characteristic in order to realize the encrypted implementation. More precisely, we rewrite the polynomial controller in terms of a code list consisting of elementary operations and derive a secure two-party computation of this list. The presented approach can be understood as a nonlinear extension to the linear two-party scheme proposed in Reference 22. The article is organized as follows. We state notation in the remainder of this section and provide background on homomorphic encryption, secret sharing, and multiparty computation in Section 2. We then summarize two encrypted linear control schemes in Section 3 that inspire our nonlinear extension. The main contribution of the article, that is, the first encrypted implementation of arbitrary polynomial control schemes, is presented in Section 4. We illustrate the proposed scheme for a numerical example in Section 5 before giving conclusions and an outlook in Section 6.

Notation
We denote the sets of real, integer, and natural (including 0) numbers by R, Z, and N, respectively. The set of positive natural numbers is abbreviated as N + . The sets Z P and Z * P refer to the additive and multiplicative group of integers modulo P ∈ N, respectively. The relation Z * P = {z ∈ Z P | gcd(z, P) = 1} connects the two groups, where gcd(z, P) refers to the greatest common divisor of z and P. We frequently consider the standard representative N P ∶= {0, … , P − 1} of Z P . We further define the set N + Q ∶= {1, … , Q} for natural numbers Q > 0 and we use the convention where ⌊⋅⌋ and ⌈⋅⌉ refer to the floor and the ceiling function, respectively.

BACKGROUND ON HOMOMORPHIC ENCRYPTION, SECRET SHARING, AND QUANTIZATION
In this section, we introduce some important ingredients for encrypted control. In particular, we briefly summarize homomorphic encryption, secret sharing, multiparty computation, and quantization of real-valued data.

Homomorphic encryption and the Paillier cryptosystem
In general, homomorphic encryption refers to a special family of cryptosystems that enables mathematical operations to be carried out on encrypted data (see, eg, . More precisely, we call a cryptosystem multiplicatively homomorphic if there exists an operation "⊗" such that the relation holds, where z 1 and z 2 are two arbitrary numbers in the message space of the cryptosystem and where the functions Enc and Dec refer to the encryption and decryption procedure, respectively. Clearly, relation (2) allows to evaluate encrypted multiplications. Analogously, cryptosystems are called additively homomorphic if an operation "⊕" exist such that encrypted additions can be realized using A popular multiplicatively homomorphic encryption scheme is the ElGamal cryptosystem. 27 Additively homomorphic encryption is often implemented using Paillier. 28 Encryption schemes that are both additively and multiplicatively homomorphic are called fully homomorphic. In principle, fully homomorphic encryption schemes can be used to encrypt arbitrary functions. 29 However, fully homomorphic encryption is computationally highly demanding and currently no competitive option for encrypted control. Nevertheless, so-called somewhat or leveled fully homomorphic encryption schemes (see, eg, Reference 30), that support a limited number of encrypted multiplications and (a limited or unlimited number of) encrypted additions, may be useful for future encrypted controller.
The majority of existing encrypted control schemes have been realized using the Paillier cryptosystem (see, eg, References [14][15][16][17][18][19][20]31,32). In this asymmetric encryption scheme, the encryption is carried out based on a public key P and the decryption requires the private key S. The key generation for the simplified Paillier scheme (see Reference 33) builds on two large primes p 1 , p 2 ∈ [2 −1 ,2 −1] of the same "bit-length" ∈ N. The public key then is P = p 1 p 2 . The private key evaluates to S = (p 1 −1)(p 2 −1). Now, the encryption of a number z from the message space Z P is realized by where r is a random number that is picked from Z * P for every single encryption. The resulting ciphertext e lies in the set Z * P 2 . The decryption is carried out by computing where S inv denotes the multiplicative inverse of S modulo P. In the following, we will restrict ourselves to messages from the set N P . We then have Dec(Enc(z,r)) = z for every z ∈ N P and every r ∈ Z * P , that is, reversibility of the encryption. The Paillier cryptosystem is additively homomorphic. In fact, we have for all z 1 , z 2 ∈ N P such that z 1 + z 2 ∈ N P and all r 1 , r 2 ∈ Z * P . In addition, the Paillier cryptosystems supports multiplications with one encrypted factor as apparent from the relation that holds for all z 1 , z 2 ∈ N P such that z 1 z 2 ∈ N P and all r ∈ Z * P . The relations (6) and (7) build the basis for many encrypted control schemes (see, eg, Sect. 3.1).

Secret sharing and multiparty computation
Secret sharing refers to procedures that allow to divide and recombine secret data in such a way that the individual shares reveal nothing about the secret. 34 More formally, a secret sharing scheme that splits secret data into N ≥ 2 shares in such a way that at least M ∈ {2,… ,N} shares are required to reconstruct the secret is called an (M,N)-threshold scheme. Here, we focus on the simplest variant of such schemes that features N = 2 shareholders. In the corresponding (2, 2)-threshold schemes, the secret data is split into two shares and both shares are required to reconstruct the secret. As an example, let us assume the secret is an integer z ∈ N Q . Then, a (2, 2)-threshold scheme can be realized as follows. A uniformly random number r ∈ N Q is generated and the ciphertext is computed. Now, the two numbers e and r can be considered as two shares of the secret z. In this context, it is easy to see that neither e nor r reveal any information on z. In fact, r is a random number and e as in (8) corresponds to the ciphertext of a so-called one-time pad. Since one-time pads are perfectly secure, 35 e reveals no information on z apart from the fact that z ∈ N Q . Nevertheless, combining the shares e and r allows to reconstruct z according to If the shares e and r are processed before recombination, multiparty computation is typically involved. More generally, secure multiparty computation (see, eg, References 36,37) provides protocols to perform computations on secret data such as secret shares. Interestingly, the one-time pad-based sharing (8) constitutes the basis for the encrypted linear control scheme in Reference 22 that is extended here.

Quantization based on fixed-point numbers
The Paillier cryptosystem in Section 2.1 and the (2,2)-threshold scheme in Section 2.2 both consider messages from a subset of the natural numbers, namely, N P , respectively, N Q . Hence, using these techniques to realize encrypted control as in Figure 1 requires to map the states x to N P or N Q . This mapping usually starts with a quantization of the real-valued states (and controller parameters). Here, we approximate the states x j ∈ R with fixed-point numbers from the set where parameters ∈ N + and , ∈ N can be understood as the basis, the magnitude, and the resolution of the fixed-point numbers, respectively. For example, for = 10 and = = 1, we obtain Q , , = {−10, −9.9, … , 9.8, 9.9}. Now, different user-defined mappings q ∶ R → Q , , (eg, rounding down or up) can be used to compute fixed-point approximations of the formx j ∶= q(x j ). We do not further specify the surjective mapping q apart from the restriction that In other words, the quantization error should be limited by the resolution for real-valued data in the range of Q , , . It remains to address the mapping from Q , , to N P , respectively, N Q . In this context, we first note that Hence, scaling with maps Q b, , onto a subset of Z. Before addressing the final mapping onto N Q , respectively, N P , we note that P is usually significantly larger that Q for security reasons. Hence, we typically have N Q ⊂ N P . As a consequence, we can use the modulo function (1) to map integers to either of the message spaces N Q and N P . The combination of the quantization via q, the scaling with , and the operation (1) leads to q(x j ) mod Q ∈ N Q . The resulting numbers can then be processed in the secret sharing scheme or the Paillier cryptosystem. To undo the transformations (apart from the surjective quantization), we exploit that ∶ Z → Z with is a partial inverse of the modulo operation (1). In fact, we have z = (z mod Q) for every

TWO INSPIRING ENCRYPTIONS OF LINEAR CONTROLLERS
As already mentioned in the introduction, the first encrypted controllers implement linear control laws of the form with K ∈ R m×n . The first provably secure implementation of (13) has been realized in Reference 12 using the multiplicatively homomorphic ElGamal cryptosystem. 27 Shortly after, an improved scheme based on additively homomorphic encryption has been proposed in Reference 14. Recently, an implementation using secret sharing and two-party computation has been presented in Reference 22. Especially the two latter schemes provide many inspirations for the encryption of polynomial control laws to be presented in Section 4. Hence, we briefly summarize these two encrypted linear controllers below.

Realization using additively homomorphic encryption
The scheme proposed in Reference 14 can be summarized as follows. First, (13) is replaced with the quantized version whereK ij ∶= q(K ij ) ∈ Q , , andx j (t) ∶= q(x j (t)) ∈ Q , , for some fixed-point set Q , , and some quantization q. Now, as an intermediate step, we note that an integer-based reformulation of (14) can be obtained with scalings similar to (11).
, where Z ij ∶=K ij andx j (t) are indeed integers. However, in order to apply the Paillier cryptosystem from Section 2.1, a natural number-based controller formulation is needed. To this end, using the modulo operation analogously to Section 2.3, we find where the second relation requires invertibility of (1) that is addressed in more detail below and where the third relation follows from basic modular arithmetic. Reformulation (15) forms the basis for the encrypted cloud-based implementation of the quantized control scheme. In fact, the sensor can now encrypt the states by evaluating Enc according to (4) for some random r j (t) ∈ Z * P . The resulting n ciphertexts are then send to the cloud, where the m control-related ciphertexts are computed by exploiting the homomorphism (6) and (7). The vector e(t) ∈ N m P 2 is then send to the actuator, where decryption yields the control actionsû according to (15). For concrete applications of the encrypted control scheme, one has to take into account that the validity of (15) and (17) is bound to some (technical) conditions. In fact, invertibility of the modulo operations in (15) requires according to (12). Moreover, reversibility of the encryption in (17) requires correctness of the homomorphic operations in (16) and consequently according to Section 2.1. Roughly speaking, both conditions prevent overflow during the computations with limited range of validity. Apparently, for a givenx(t), it is straightforward to choose P and Q sufficiently large. Similarly, a suitable choice for P and Q can be derived under the (realistic) assumption that the states x(t) occurring during runtime are bounded. We stress, however, that the choice of P is typically not limited by (19) but by the length of the primes p 1 and p 2 (see Section 2.1) required to guarantee security. In fact, the current recommendation by the National Institute of Standards and Technology is to choose at least l = 1024 leading to a 2048-bit public key P, that is, P ≈ 2 2048 (see [38, Tabs. 2 and 4]).

Realization using two-party computation
Homomorphic cryptosystems such as Paillier are typically asymmetric schemes. One characteristic of asymmetric encryption is that only the decryption requires a secret key. In fact, the key for encryption (ie, also required for homomorphic operations) is public (cf. Sect. 2.1). By contrast, symmetric cryptosystems such as AES use one secret key for both encryption and decryption. Asymmetric encryption is quite useful for securing digital communications such as e-mails since exchanging a secret key between sender and receiver is not required. However, if a lot of data has to be transmitted between a fixed sender-receiver pair, symmetric cryptosystems are significantly more efficient than public-key schemes. One reason is that the numerical effort for asymmetric encryption and decryption is often (significantly) higher than for the symmetric counterparts. Moreover, the ciphertext expansion, that is, the relative "length" of the ciphertext compared with the plaintext, is typically (significantly) higher for asymmetric cryptosystems. For instance, the Paillier encryption (4) transforms a message from Z P into a ciphertext from Z * P 2 , that is, the ciphertext (in bits) is twice as long as the plaintext.
For most networked control systems, the sender-receiver pairs (eg, sensor-cloud or cloud-actuator) are fixed. Hence, asymmetric encryption is utilized only because of the homomorphic properties of some of these cryptosystems. However, as briefly discussed in Section 2.2, secure computations over clouds can also be realized based on secret sharing and multiparty computation. This observation has been exploited in Reference 22 in order to implement an encrypted linear controller using two-party computation. The simple approach also builds on the natural number-based controller formulation (15). However, instead of encrypting via Paillier, the natural numbersx j (t) mod Q are now shared according to (8). Hence, the sensor generates a random vector r(t) ∈ N n Q and computes The shares e(t) and r(t) are then send to the first and second cloud, respectively. In the two clouds, the shares are processed by computing respectively, where Z is defined as before (ie, Z ∶=K). Afterward, the processed shares s(t) ∈ N m Q and (t) ∈ N m Q are forwarded to the actuator, where the control actionŝ are obtained according to (9) and (15). The resulting two-party computation is shown on the left in Figure 2. Similarly to the scheme above, validity of (17) is bound to conditions. In fact, we again require invertibility of (1) in (15) and hence (18).

ENCRYPTED POLYNOMIAL CONTROL
The remaining article focuses on an encrypted implementation of polynomial controllers. More precisely, we consider control laws of the form u(t) = g(x(t)), where g ∶ R n → R m is a polynomial function of degree d ∈ N. Hence, each g i can be written as a linear combination of products of the form x 1 1 … x n n with j ∈ N and ∑ n j=1 j ≤ d. For example, for m = 2, n = 3, and d = 4, g could read .
The encrypted implementation of polynomial control laws as in (23) is realized by three steps. First, we introduce code lists for a structured representation of polynomial functions. Second, an integer-based reformulation of the code lists is presented. Third, secret sharing and tailored two-party computation is applied.

Structure of polynomial control schemes and code lists
An important characteristic of polynomials is the fact that they can be decomposed into a finite number of multiplications and additions. The required number of operations can, however, significantly change with the representation of g. In fact, naively implementing g 1 in (23) requires 32 multiplications and seven additions. Clearly, products of the form x j can more efficiently be implemented as exponentiations, which reduces the operation count to nine exponentiations (with natural exponents), 17 multiplications, and seven additions. However, a more significant reduction can be achieved, if is considered instead of (23). Now, it is easy to verify that (23) and (24) implement the same functionality. However, evaluating g 1 in (24) only requires one exponentiation, four multiplications, and two additions. In general, fewer operations are beneficial for efficient implementations. A "minimal" representation is, however, not necessarily required here. Yet, we assume that the implementation of g is fixed a priori in terms of a code list of the form In summary, we consider the five operations add, mul, addC, mulByC, and powN that are specified in the second column of Table 1. Finally, the last m lines of the code list specify the control actions u 1 ,… ,u m , that is, the outputs of g, by referring to the corresponding intermediate results.
To further illustrate the concept of code lists, we exemplary state the implementation y 5 ∶= 1.25y 2 , y 12 ∶= y 7 y 10 , y 6 ∶= 0.64y 3 , u 1 ∶= y 11 , y 7 ∶= y 4 + y 5 , u 2 ∶= y 12 of g as in (24), where we note that the two-column format in (26) is solely used for compactness. We obviously require (in this order) 3 mulByC, 2 add, 2 powN (with = 3) , and 2 mul operations to simultaneously evaluate g 1 and g 2 . Code lists offer interesting properties beyond a structured representation of a function. In fact, the various code list lines can be easy overloaded to increase the functionality of the code list. This feature is, for example, intensively used in the framework of automatic differentiation (see, eg, Reference 39). Here, we will substitute the various code list lines with integer-based counterparts to prepare the encrypted evaluation of g. Before detailing this approach in the following section, we briefly note that code lists as in (25) or (26)  and arithmetic circuits. 40 Hence, it would be straightforward to adapt the following method to these representations of polynomials.

Quantization and integer-based reformulation
Inspired by the encrypted linear controllers in Section 3, we consider a quantization of g and a subsequent integer-based reformulation in order to prepare the encrypted implementation. Roughly speaking, the quantization of g is realized by replacing all states x j and all appearing constants c with their quantized versionsx j ∶= q(x j ) andĉ ∶= q(c), respectively. As a result, we obtain a quantized controllerĝ(x) that may look likê for g as in (24), fixed-point numbers from Q 10,1,1 , and the quantizer (ie, rounding down). We note that the quantization of the states is recurringly performed online for the current state x(t) while the constants are quantized offline only once. We further note that the quantization can also be carried out based on the code list describing g. In fact, the quantization of (26) with Q 10,1,1 and h as above yieldŝ y 1 ∶=x 1 ,ŷ 8 ∶=ŷ 1 +ŷ 6 , y 2 ∶=x 2 ,ŷ 9 ∶=ŷ 3 7 , y 3 ∶=x 3 ,ŷ 10 ∶=ŷ 3 8 , y 5 ∶= 1.2ŷ 2 ,ŷ 12 ∶=ŷ 7ŷ10 , y 6 ∶= 0.6ŷ 3 ,û 1 ∶=ŷ 11 , y 7 ∶=ŷ 4 +ŷ 5 ,û 2 ∶=ŷ 12 in line with (27). In general, the intermediate results of a quantized code list (slightly) differ from the original. We highlight this fact by introducingŷ i as a counterpart to y i . For completeness, we also list quantized versions of the considered operational lines in the third column of Table 1. We next address an integer-based implementation ofĝ(x) or, more precisely, of the corresponding code list. The leading idea is to substitute the quantized code list lines with integer-based counterparts. Regarding the n input lines, a suitable substitution is straightforward (and suggested by (11)). In fact, multiplying the quantized statex j ∈ Q , , with the factor already yields z j ∶=x j ∈ Z. Before addressing the operational lines, we discuss a simple thought experiment and assume, for the moment, that g i , that is, the control actionû i , is equivalent tox j . The corresponding output line would then refer to the jth code list line. Hence, for the integer-based reformulation,û i =x j has to be reconstructed from z j . Apparently, this reconstruction is only feasible if information on the applied scaling factor, that is, for the experiment, is available. It will turn out in the following that the scaling factors change during some operations. However, the scaling factors will always be of the form with the fixed basis (defined by the quantization scheme) but varying exponents . We will hence associate an exponent i , that allows to recoverŷ i from z i , with every code list line i and forward it alongside with z i . Regarding an input line j, this approach obviously leads to j = . To derive suitable exponents for the operational lines, we study every operation separately. Starting with the add-operation and its quantized version, we initially find where we assume that an integer-based representation of the lines j and k is available in terms of z j , z k ∈ Z and j , k ∈ N.
As apparent from (30), for j ≠ k , it is not straightforward to expressŷ i as − i z i (with z i ∈ Z and i ∈ N) without further ado. A suitable representation can, however, be obtained by computing In fact, we have by construction. Moreover, we find z i ∈ Z and i ∈ N, where the former holds due to i − j ∈ N + and i − k ∈ N + . The computation rules (31) are summarized in the fourth and fifth column of Table 1 together with rules for the other operations.
To establish the correctness of the rules more formally, we state the following proposition.

Proposition 1.
Let , ∈ N + , , ∈ N,ŷ j ,ŷ k ∈ R, andĉ ∈ Q , , and assume that z j , z k ∈ Z and j , k ∈ N with min{ j , k } ≥ are such thatŷ j = − j z j andŷ k = − k z k . Consider any of the operations add, mul, addC, mulByC, or powN and defineŷ i , z i , and i according to the corresponding rules in Table 1. Then,ŷ i = − i z i , z i ∈ Z, and i ∈ N with i ≥ .
Proof. Regarding the add operation, a formal proof can be obtained along the previously discussed line of argumentation.
For the mul operation, we find Moreover, we have z i = z j z k ∈ Z and i = j + k ∈ N with i ≥ 2 ≥ . Analogously, for addC and mulByC, we obtain respectively. In both cases, we obviously have i ∈ N with i ≥ j ≥ . Moreover, we have z i ∈ Z in both cases sinceĉ ∈ Z due toĉ ∈ Q , , and since jĉ = j −ĉ ∈ Z due to j − ∈ N + . Finally, the powN operation result in Due to ∈ N + , we clearly have z i ∈ Z and i = j ∈ N with i ≥ ≥ as required. ▪ Remark 1. In Proposition 1, real-valuedŷ j andŷ k are considered although the quantized code list is addressed. At first sight, this condition seems slightly unspecific since the quantized implementation builds on quantized statesx j and quantized constantsĉ from Q , , . However, without knowing the "history" of the code list lines j and k, it is impossible to specify the "level" of quantization ofŷ j andŷ k . To see this, we first note that the required resolution of the quantization might change with every code list line. Consider, for example, the multiplication of the two numbers 0.8 and 1.3 from Q 10,1,1 . Then, the result 1.04 is not contained in Q 10,1,1 but part of Q 10,1,2 . Hence, the required resolution is changing from = 1 for the factors to = 1 + 1 = 2 for the product. In general, a sufficient resolution to represent the product is given in terms of the sum of the resolutions of the factors. Apparently, this rule is already covered in Table 1 in terms of the rule i = j + k for the mul operation. Analogously, the rules for the computation of i for the other operations refer to changes of the resolution required for these types of operations. In summary, the difference i − can be interpreted as the level of quantization of line i with level 0 referring to lines for which the original resolution is sufficient (eg, input lines).

Operation
Integer-based Exponent First share Second share The entries for z i and i are copied from Table 1 and restated for convenience.
Proposition 1 provides the basis for a complete integer-based reformulation of a quantized code list. In fact, the statement of Proposition 1 is recursively used to prove the following proposition.

Proposition 2.
Let , l, m, n ∈ N + and , ∈ N and assume that a quantized code list is given that consists of n input lineŝ y 1 =x 1 , … ,ŷ n =x n , l lines with operations from the third column in Table 2, and m output lines providing the control actionŝ Table 2, where the exponents i are defined according to the fifth column. Furthermore, replace the m output linesû i =ŷ j i withû i = − j i z j i . Then, for every quantized statex ∈ Q n , , , the two code lists provide the same outputsû 1 , … ,û m .

n+l}. Define an integer-based reformulation of the code list by replacing the n inputs lines and the l operational lines with the corresponding substitution z i from the fourth column of
Proof. We prove the claim by showing that the relation holds for all input lines and all operational lines. Equality of the outputs then follows by construction of the replaced outputs and the condition j i ∈{1, … , n+l}. Now, for the n inputs lines, we have (32) by definition ofŷ i , z i , and i = in Table 1 (see the input-row). For the following l operational lines, we prove (32) by induction. More precisely, we show that (32) holds for some line i∈{n+1,… ,n+l} if it is valid for all previous lines {1,… ,i−1}. To this end, we first note that every line i ∈ {n+1,… ,n+l} refers to one of the operations add, mul, addC, mulByC, or powN specified in Table 1. Moreover, the individual operations involve one or two previous code lines j,k ∈ {1,… ,i−1}. For the induction step, we will now consider some i ∈ {n+1,… ,n+l} and apply Proposition 1. Clearly, having (32) for all previous lines impliesŷ j = − j z j and y k = − k z k for all j,k ∈ {1,… ,i−1}. Hence, Proposition 1 immediately provides (32) for the consider i if the additional conditions z j , z k ∈ Z and j , k ∈ N with min{ j , k } ≥ are satisfied. It is easy to show that these conditions hold for all input lines. Hence, Proposition 1 can be used to prove (32) for the base case i = n+1. Taking into account that Proposition 1 not only guarantees (32) but also z i ∈ Z and i ∈ N with i ≥ , completes the proof by induction. ▪ In order to verify the statement of Proposition 2, we evaluate (29) and (33) for the quantized statex = ( 1.3 0.5 −0.7 ) ⊤ ∈ Q 3 10,1,1 and indeed obtain the same resultû ≈ Finally, it is interesting to note that the exponents i in (33) do not depend on the "inserted" statex. Hence, it is convenient to compute the exponents only once offline.

Encrypted implementation using tailored two-party computation
Inspired by the linear two-party scheme in Section 3.2, the leading idea for the encrypted implementation of the polynomial controller is two divide the integer-based reformulation of the controller into two shares. By contrast to (21), this cannot be realized within a single equation here. However, the sharing can intuitively be carried out for the individual code list lines. As a result, we will obtain two code lists that we implement separately in two clouds. We denote the intermediate results of these code lists with s i , respectively, i . Now, the sharing of the integer-based input lines z i =x i is realized analogously to (20). In fact, we consider the shares where r i ∈ N Q is picked uniformly at random. By construction and according to (9), the shares are such that we have for every i ∈ {1,… ,n}. We next divide each of the l operational lines z i into two shares that satisfy (36). The resulting shares are summarized in the fourth and fifth column of Table 2 and formalized in the following proposition.

Proposition 3.
Let , , Q ∈ N + , , , j , k ∈ N, andĉ ∈ Q , , and assume that z j , z k , s j , s k , j , k ∈ Z are such that z j mod Q = s j + j mod Q and z k mod Q = s k + k mod Q holds. Consider any of the operations add, mul, addC, mulByC, pow2, or pow3 and define z i , s i , and i according to the corresponding rules in Table 2 with r i , i ∈ Z Q . Then, (36) holds.
Proof. The proof follows the same steps for every operation. In fact, we start with the expression s i + i mod Q in each case and substitute the corresponding entries for s i and i from the fourth and fifth column of Table 2, respectively. In the resulting expression, the terms s j + j mod Q and, if applicable, s k + k mod Q are isolated and substituted with z j mod Q and z k mod Q, respectively. Finally, simple manipulations (involving modular arithmetic) are carried out until the expression for z i in second column of Table 2 is recovered. Regarding the add operation, the discussed steps lead to Analogously, for the mul operation, we obtain where we note that the numbers r i and i have no effect on the equation. We omit detailed inspections of the other operations since they are straightforward and similar to the two presented cases. ▪ Remark 2. Two features of Table 2 need some clarification. First, instead of the operation powN specified in Tables 1 and  2 lists the two special cases pow2 and pow3. This restriction is mainly introduced to simplify the encrypted implementation of the operations further below. Apparently, we can still handle exponentiation for arbitrary natural numbers. For example, z 4 and z 5 can be written as (z 2 ) 2 and (z 2 )(z 3 ), respectively. Moreover, an encrypted implementation of powN can, in principle, be realized analogously to the procedures for pow2 and pow3. The second feature that needs clarification is the appearance of the numbers r i and i in the shares of the operations mul, pow2, and pow3. As apparent from Table 2, evaluating the shares s i and i for those operations requires data-exchange between the two code lists. A secure implementation of such communications will require "rerandomization" of the shares and this will be realized with the help of the random numbers r i and i as specified further below.
Proposition 3 provides the basis for a two-party evaluation of integer-based code lists. The corresponding procedure, underlying conditions, and the recombination of the shares are formalized in the following proposition.

Proposition 4.
Let , l, m, n, Q ∈ N + and , ∈ N and assume that an integer-based code list is given that consists of n input lines z 1 =x 1 , … , z n =x n , l lines with operations from the second column in Table 2, and m output lines providing the control actionsû 1 = − j 1 z j 1 , … ,û m = − j m z j m with j 1 ,… ,j m ∈{1,… ,n+l} and j 1 , … , j m ∈ N. Furthermore, assume that for every i ∈ {1,… ,m}. Define a two-party reformulation of the code list by replacing the n inputs lines and the l operational lines with the corresponding shares s i and i from the fourth and fifth column of Table 2, respectively. Furthermore, replace the m output lines with the recombinationû of the shares. Then, for every quantized statex ∈ Q n , , and all r i , i ∈ Z Q , the integer-based code list and the two-party realization provide the same outputsû 1 , … ,û m .
We illustrate the concept for the pow2 operation. According to Table 2, computing the share s i ∶= s 2 j + 2s j j + i mod Q in the first cloud requires the share j of the second cloud. Clearly, providing j in plaintext to the first cloud would allow to infer information about z j from the relation z j = s j + j mod Q, which is a security threat. To avoid this situation, the first cloud sets up a Paillier cryptosystem by generating a public key P 1 and a secret key S 1 according to Section 2.1. It then computes the ciphertext e i : = Enc 1 (s j ,⋅), where we omit the random element for better readability, and sends e i to the second cloud that has access to P 1 but not to S 1 . Using the homomorphism (7), the second cloud is able to evaluate 2s j j in an encrypted fashion by computing e 2 j i . However, before returning the resulting ciphertext, the second cloud has to make sure that the first cloud cannot reconstruct j from the decrypted value. To this end, it generates a (secret) random number i ∈ N Q and adds it to the encrypted product 2s j j using the homomorphism (6). More precisely, the second cloud computes the ciphertext i ∶= e 2 j i Enc 1 ( i , ⋅) mod P 2 1 and sends it to the first clouds. The first cloud then computes which is equivalent to the desired share s i if 2s j j + i ≤P 1 −1 is satisfied (analogously to condition (19)). Finally, in order to compensate the effect of i , the second cloud computes its own share by evaluating i ∶= 2 j − i mod Q according to Table 2. Apparently, under the proposed protocol, neither the first nor the second cloud get plaintext access to both shares s j and j . The encrypted communication protocol is summarized in Table 3 together with the protocols for the mul and pow3 operations. The secure computation of the shares is specified in Table 4. The correctness of the listed relations is formalized in the following proposition.

Proposition 5.
Let Q ∈ N + and s j , s k , j , k , r i , i ∈ N Q . Furthermore, let P 1 , P 2 ∈ N + and S 1 , S 2 ∈ N + be the public, respectively, private keys of two Paillier cryptosystems and assume that Consider any of the operations mul, pow2, or pow3 and define s i and i according to the corresponding rules in Table 4. Then, s i and i are identical to the corresponding entries in Table 2.
Proof. We exemplary prove the claim for the mul operation and the share s i and leave the remaining cases for the interested reader. From Table 4, we infer s i ∶= s j s k − r i + Dec 1 ( i ) mod Q. Substituting the corresponding The homomorphic operations in the 2nd communication round build on the received ciphertexts e i , respectively, i from the first round. Validity of the homomorphisms is guaranteed if the limiters are smaller than min{P 1 , P 2 }.

Operation
Secure first share Secure second share The ciphertexts e i and i refer to the corresponding data from the second communication round in Table 3.

TA B L E 4 Secure computation of the
shares for the operations mul, pow2, and pow3 from Table 3 yields that is, the entry for s i in Table 2, presupposed that s j k + i ≤P 1 −1. Due to s j , k , i ∈ N Q , the latter condition always holds since is guaranteed by assumption (40). ▪ Proposition 5 states that the proposed data-exchange protocols can be applied whenever (40) holds. In practice, this is not a restriction since we will typically apply Q ∈ [2 16 , 2 64 ] and P 1 ≈P 2 at least of the order 2 2048 . We have now collected and specified all elements required for encrypted polynomial control. It remains to briefly comment on the actual security of the resulting scheme. We recall that we use one-time pads for secret sharing, symmetric encryption such as AES for communications between the pairs sensor-cloud and cloud-actuator, and Paillier encryption for secure data-exchange between the two noncolluding clouds. Since all cryptosystems are used out of the box, we inherit the corresponding security guarantees. According to Section 2.2 and Reference 35, one-time pads are perfectly secure. Hence, the shares s i and i reveal no information on z i beyond the requirement that (37) holds for the outputs. The Paillier scheme is not perfectly but semantically secure (see, eg, [33, def. 3.12] for details). In particular, Paillier is semantically secure against chosen-plaintext attacks. In other words, even if an attacker gets access to an unsorted list of ciphertexts for plaintexts of his/her choice, the ciphertexts are indistinguishable for the attacker. Indistinguishability under chosen-plaintext attack is considered to provide sufficient security for most real-world applications. Hence, we complete the description of the encrypted controller by summarizing the proposed offline and online procedures. The online scheme is additionally shown in Figure 2 (on the right).

NUMERICAL EXAMPLE
We consider the nonlinear continuous-time systeṁ with the time constant T = 1000 to illustrate the proposed control scheme. We note that, for T = 1, (41) would be identical to the system considered in [26,Exmp. 3]. Clearly, T≫1 as considered here slows down the system dynamics, which is in favor of our method. We believe that the modification is uncritical, for the moment, since (41) does not reflect a real-world application. However, we discuss possible improvements of our method in Section 6 that might allow to deal with (41) and T = 1. Now, in Reference 26, the polynomial control law (42) has been derived for (41) and T = 1 in order to maximize the domain of attraction of the closed-loop system (see [26, Eq. (56) and Fig. 1]). Since the objective is independent of the time t, (42) provides appropriate control actions although for T = 1000 as in our case. In the following, we implement (42) using the proposed two-party scheme in a zero-hold fashion with a sampling time of Δt = 1 s .

Analysis and encrypted implementation of the controller
Similar to (23), the representation of g in (42) is suboptimal for our purpose. We hence consider a reformulation of the form g(x) = c 0 + c 1 x 1 + c 2 x 2 + c 3 x 2 1 + (c 4 x 1 + c 5 x 2 + c 6 ) 3 + (c 7 x 1 + c 8 x 2 + c 9 ) 3 (43) and find the constants To conclude the numerical analysis, we briefly comment on the real-time capability of the proposed scheme. For the 5000 simulated controller evaluations, we observed, on average, an accumulated computation time of 762.13 milliseconds for evaluating the shares at the sensor, the AES encryptions and decryptions for the pairs sensor-cloud and cloud-actuator, the code lists in the two clouds, and the recombination of the shares at the actuator. Hence, the proposed scheme is, in principle, real-time capable. We note, however, that the two clouds have, so far, only been emulated on a single platform that runs Python scripts on a 2.7 GHz Intel Core i7-7500U. Moreover, communication latencies have not been taken into account yet. We assume, in addition, that the two clouds work in parallel. In particular, we assume that the computations associated with the first, respectively, second communication round of the data-exchange protocols are performed in parallel (see Tab. 3). However, the various code list lines and the mentioned communication rounds are evaluated one by one. Finally, we assume that random numbers are generated (online or offline) before use. Hence, their generation is not including in the above computation time.

CONCLUSIONS AND OUTLOOK
We presented a novel and flexible method for the encrypted implementation of arbitrary polynomial controllers. The procedure builds on a tailored two-party implementation that is derived from a code list representation of the control law. The method can be understood as a nonlinear extension to the encrypted linear control scheme in Reference 22. The main difference between the two approaches is that the secure evaluation of polynomials requires communication between the two noncolluding clouds whereas linear operations can be evaluated independently (see Figure 2). We implemented secure data-exchange protocols that maintain the confidentiality of the individual shares, using additively homomorphic encryption. In summary, the scheme uses various cryptographic techniques for encrypted computations. In fact, elements from secret sharing, multiparty computation, and homomorphic encryption are involved. The effectiveness of the proposed scheme has been illustrated with a numerical example. The exemplary application showed that sampling times around one second can, in principle, be met. However, studying the computational effort in more detail, it turns out that roughly 99% of the computations are related to the homomorphic data-exchange protocols summarized in Table 3. Hence, future research should address an alternative to the additively homomorphic Paillier scheme. In this context, it is interesting to note that there exist secure multiparty computation protocols that offer similar properties as the proposed scheme. In fact, the Goldreich, Micali, and Wigderson protocol 41 and the Ben-Or, Goldwasser, and Wigderson protocol 42 both enable secure evaluations of arithmetic circuits that are quite similar to the considered code lists. Moreover, garbled circuits (see, eg, Reference 43) could, in principle, be used to securely evaluated the shared code lists. A more detailed investigation of similarities and differences between the these protocols is another line for future research. Finally, encrypted computations typically require quantizations. We carefully addressed this fact for the design of our encrypted control scheme. However, analyzing the effect of the involved quantization errors on the closed-loop dynamics is ongoing research. In this context, similar studies for other encrypted control schemes 14,15,31 show that methods from robust control often allow to ensure closed-loop stability despite quantization errors. This provides a promising direction for future research since robust polynomial control has already been intensively studied in the literature (see, eg, References 44,45).