Oblivious Online Monitoring for Safety LTL Specification via Fully Homomorphic Encryption

Abstract

In many Internet of Things (IoT) applications, data sensed by an IoT device are continuously sent to the server and monitored against a specification. Since the data often contain sensitive information, and the monitored specification is usually proprietary, both must be kept private from the other end. We propose a protocol to conduct oblivious online monitoring—online monitoring conducted without revealing the private information of each party to the other—against a safety LTL specification. In our protocol, we first convert a safety LTL formula into a DFA and conduct online monitoring with the DFA. Based on fully homomorphic encryption (FHE), we propose two online algorithms (Reverse and Block) to run a DFA obliviously. We prove the correctness and security of our entire protocol. We also show the scalability of our algorithms theoretically and empirically. Our case study shows that our algorithms are fast enough to monitor blood glucose levels online, demonstrating our protocol’s practical relevance.

1 Introduction

Internet of Things (IoT) [3] devices enable various service providers to monitor personal data of their users and to provide useful feedback to the users. For example, a smart home system can save lives by raising an alarm when a gas stove is left on to prevent a fire. Such a system is realized by the continuous monitoring of the data from the IoT devices in the house [8, 18]. Another application of IoT devices is medical IoT (MIoT) [16]. In MIoT applications, biological information, such as electrocardiograms or blood glucose levels, is monitored, and the user is notified when an abnormality is detected (such as arrhythmia or hyperglycemia).

Fig. 1.

The proposed oblivious online LTL monitoring protocol.

In many IoT applications, monitoring must be conducted online, i.e., a stream of sensed data is continuously monitored, and the violation of the monitoring specification must be reported even before the entire data are obtained. In the smart home and MIoT applications, online monitoring is usually required, as continuous sensing is crucial for the immediate notifications to emergency responders, such as police officers or doctors, for the ongoing abnormal situations.

As specifications generally contain proprietary information or sensitive parameters learned from private data (e.g., with specification mining [27]), the specifications must be kept secret. One of the approaches for this privacy is to adopt the client-server model to the monitoring system. In such a model, the sensing device sends the collected data to a server, where the server performs the necessary analyses and returns the results to the device. Since the client does not have access to the specification, the server’s privacy is preserved.

However, the client-server model does not inherently protect the client’s privacy from the servers, as the data collected from and results sent back to the users are revealed to the servers in this model; that is to say, a user has to trust the server. This trust is problematic if, for example, the server itself intentionally or unintentionally leaks sensitive data of device users to an unauthorized party. Thus, we argue that a monitoring procedure should achieve the following goals:

Online Monitoring.:

The monitored data need not be known beforehand.

Client’s Privacy.:

The server shall not know the monitored data and results.

Server’s Privacy.:

The client shall not know what property is monitored.

We call a monitoring scheme with these properties oblivious online monitoring. By an oblivious online monitoring procedure, 1) a user can get a monitoring result hiding her sensitive data and the result itself from a server, and 2) a server can conduct online monitoring hiding the specification from the user.

Fig. 2.

How our algorithms consume the data $d_1, d_2,\dots ,d_n$ with the DFA M.

Contribution. In this paper, we propose a novel protocol (Fig. 1) for oblivious online monitoring against a specification in linear temporal logic (LTL) [33]. More precisely, we use a safety LTL formula [26] as a specification, which can be translated to a deterministic finite automaton (DFA) [36]. In our protocol, we first convert a safety LTL formula into a DFA and conduct online monitoring with the DFA. For online and oblivious execution of a DFA, we propose two algorithms based on fully homomorphic encryption (FHE). FHE allows us to evaluate an arbitrary function over ciphertexts, and there is an FHE-based algorithm to evaluate a DFA obliviously [13]. However, this algorithm is limited to leveled homomorphic, i.e., the FHE parameters are dependent on the number of the monitored ciphertexts and thus not applicable to online monitoring.

In this work, we first present a fully homomorphic offline DFA evaluation algorithm (Offline) by extending the leveled homomorphic algorithm in [13]. Although we can remove the parameter dependence using this method, Offline consumes the ciphertexts from back to front (Fig. 2a). As a result, Offline is still limited to offline usage only. To truly enable online monitoring, we propose two new algorithms based on Offline: Reverse and Block. In Reverse, we reverse the DFA and apply Offline to the reversed DFA (Fig. 2b). In Block, we split the monitored ciphertexts into fixed-length blocks and process each block sequentially with Offline (Fig. 2c). We prove that both of the algorithms have linear time complexity and constant space complexity to the length of the monitored ciphertexts, which guarantees the scalability of our entire protocol.

On top of our online algorithms, we propose a protocol for oblivious online LTL monitoring. We assume that the client is malicious, i.e., the client can deviate arbitrarily from the protocol, while the server is honest-but-curious, i.e., the server honestly follows the protocol but tries to learn the client’s private data by exploiting the obtained information. We show that the privacy of both parties can be protected under the standard IND-CPA security of FHE schemes with the addition of shielded randomness leakage (SRL) security [10, 21].

We implemented our algorithms for DFA evaluation in C++20 and evaluated their performance. Our experiment results confirm the scalability of our algorithms. Moreover, through a case study on blood glucose levels monitoring, we also show that our algorithms run fast enough for online monitoring, i.e., our algorithms are faster than the sampling interval of the current commercial devices that samples glucose levels.

Our contributions are summarized as follows:

• We propose two online algorithms to run a DFA obliviously.

• We propose the first protocol for oblivious online LTL monitoring.

• We proved the correctness and security of our protocol.

• Our experiments show the scalability and practicality of our algorithms.

Related Work. There are various works on DFA execution without revealing the monitored data (See Table 1 for a summary). However, to our knowledge, there is no existing work achieving all of our three goals (i.e., online monitoring, privacy of the client, and privacy of the server) simultaneously. Therefore, none of them is applicable to oblivious online LTL monitoring.

Homomorphic encryption, which we also utilize, has been used to run a DFA obliviously [13, 25]. Among different homomorphic encryption schemes, our algorithm is based on the algorithm in [13]. Although these algorithms guarantee the privacy of the client and the privacy of the server, all of the homomorphic-encryption-based algorithms are limited to offline DFA execution and do not achieve online monitoring. We note that the extension of [13] for online DFA execution is one of our technical contributions.

In [1], the authors propose an LTL runtime verification algorithm without revealing the monitored data to the server. They propose both offline and online algorithms to run a DFA converted from a safety LTL formula. The main issue with their online algorithm is that the DFA running on the server must be revealed to the client, and the goal of privacy of the server is not satisfied.

Oblivious DFA evaluation (ODFA) [9, 20, 22, 31, 35, 37] is a technique to run a DFA on a server while keeping the DFA secret to the server and the monitored data secret to the client. Although the structure of the DFA is not revealed to the client, the client has to know the number of the states. Consequently, the goal privacy of the server is satisfied only partially. Moreover, to the best of our knowledge, none of the ODFA-based algorithms support online DFA execution. Therefore, the goal online monitoring is not satisfied.

Organization. The rest of the paper is organized as follows: In (Sect. 2), we overview LTL monitoring (Sect. 2.1), the FHE scheme we use (Sect. 2.2), and the leveled homomorphic offline algorithm (Sect. 2.3). Then, in Sect. 3, we explain our fully homomorphic offline algorithm (Offline) and two online algorithms (Reverse and Block). We describe the proposed protocol for oblivious online LTL monitoring in Sect. 4. After we discuss our experimental results in Sect. 5, we conclude our paper in Sect. 6.

Table 1. Related work on DFA execution with privacy of the client.

2 Preliminaries

Notations. We denote the set of all nonnegative integers by $\mathbb {N}$, the set of all positive integers by $\mathbb {N}^+$, and the set $\{0,1\}$ by $\mathbb {B}$. Let X be a set. We write $2^X$ for the powerset of X. We write $X^*$ for the set of finite sequences of X elements and $X^\omega$ for the set of infinite sequences of X elements. For $u \in X^\omega$, we write $u_i \in X$ for the i-th element (0-based) of u, $u_{i:j} \in X^*$ for the subsequence $u_i, u_{i+1}, \dots , u_{j}$ of u, and $u_{i:} \in X^\omega$ for the suffix of u starting from its i-th element. For $u \in X^*$ and $v \in X^* \cup X^\omega$, we write $u \cdot v$ for the concatenation of u and v.

DFA. A deterministic finite automaton (DFA) is a 5-tuple $(Q, \Sigma , \delta , q_0, F)$, where Q is a finite set of states, $\Sigma$ is a finite set of alphabet, $\delta :Q\times \Sigma \rightarrow Q$ is a transition function, $q_0\in Q$ is an initial state, and $F\subseteq Q$ is a set of final states. If the alphabet of a DFA is $\mathbb {B}$, we call it a binary DFA. For a state $q\in Q$ and a word $w=\sigma _1\sigma _2\dots \sigma _{n}$ we define $\delta (q,w){:}{=}\delta (\dots \delta (\delta (q,\sigma _1),\sigma _2),\dots ,\sigma _{n})$. For a DFA M and a word w, we write $M(w){:}{=}1$ if M accepts w; otherwise, $M(w) {:}{=}0$. We also abuse the above notations for nondeterministic finite automata (NFAs).

2.1 LTL

We use linear temporal logic (LTL) [33] to specify the monitored properties. The following BNF defines the syntax of LTL formulae: $\phi ,\psi \,{:}{:}\!\!= \top \mid p \mid \lnot \phi \mid \phi \wedge \psi \mid \mathsf {X}\phi \mid \phi \mathsf {U}\psi$, where $\phi$ and $\psi$ range over LTL formulae and p ranges over a set $\mathrm {AP}$ of atomic propositions.

An LTL formula asserts a property of $u \in (2^\mathrm {AP})^\omega$. The sequence u expresses an execution trace of a system; $u_i$ is the set of the atomic propositions satisfied at the i-th time step. Intuitively, $\top$ represents an always-true proposition; p asserts that $u_0$ contains p, and hence p holds at the 0-th step in u; $\lnot \phi$ is the negation of $\phi$; and $\phi \wedge \psi$ is the conjunction of $\phi$ and $\psi$. The temporal proposition $\mathsf {X} \phi$ expresses that $\phi$ holds from the next step (i.e., $u_{1:}$); $\phi \mathsf {U} \psi$ expresses that $\psi$ holds eventually and $\phi$ continues to hold until then. We write $\bot$ for $\lnot \top$; $\phi \vee \psi$ for $\lnot (\lnot \phi \wedge \lnot \psi )$; $\phi \implies \psi$ for $\lnot \phi \vee \psi$; $\mathsf {F}\phi$ for $\top \mathsf {U} \phi$; $\mathsf {G}\phi$ for $\lnot (\mathsf {F} \lnot \phi )$; $\mathsf {G}_{[n,m]}\phi$ for $\overbrace{\mathsf {X}\dots \mathsf {X}}^{n\text { occurrences of }\mathsf {X}}(\phi \wedge \overbrace{\mathsf {X}(\phi \wedge \mathsf {X}(\dots \wedge \mathsf {X}\phi ))}^{(m-n)\text { occ. of }\mathsf {X}})$; and $\mathsf {F}_{[n,m]}\phi$ for $\overbrace{\mathsf {X}\dots \mathsf {X}}^{n\text { occ. of }\mathsf {X}}(\phi \vee \overbrace{\mathsf {X}(\phi \vee \mathsf {X}(\dots \vee \mathsf {X}\phi ))}^{(m-n)\text { occ. of }\mathsf {X}})$.

We formally define the semantics of LTL below. Let $u \in (2^{\mathrm {AP}})^{\omega }$, $i\in \mathbb {N}$, and $\phi$ be an LTL formula. We define the relation $u,i \models \phi$ as the least relation that satisfies the following:

We write $u \models \phi$ for $u,0\models \phi$ and say u satisfies $\phi$.

In this paper, we focus on safety [26] (i.e., nothing bad happens) fragment of LTL properties. A finite sequence $w \in (2^{\mathrm {AP}})^{*}$ is a bad prefix for an LTL formula $\phi$ if $w\cdot v\not \models \phi$ holds for any $v\in (2^\mathrm {AP})^\omega$. For any bad prefix w, we cannot extend w to an infinite word that satisfies $\phi$. An LTL formula $\phi$ is a safety LTL formula if for any $w\in (2^\mathrm {AP})^\omega$ satisfying $w\not \models \phi$, w has a bad prefix for $\phi$.

A safety monitor (or simply a monitor) is a procedure that takes $w \in (2^\mathrm {AP})^\omega$ and a safety LTL formula $\phi$ and generates an alert if $w \not \models \phi$. From the definition of safety LTL, it suffices for a monitor to detect a bad prefix of $\phi$. It is known that, for any safety LTL formula $\phi$, we can construct a DFA $M_{\phi }$ recognizing the set of the bad prefixes of $\phi$ [36], which can be used as a monitor.

Table 2. Summary of TFHE ciphertexts, where N is a parameter of TFHE.

2.2 Torus Fully Homomorphic Encryption

Homomorphic encryption (HE) is a form of encryption that enables us to apply operations to encrypted values without decrypting them. In particular, a type of HE, called Fully HE (FHE), allows us to evaluate arbitrary functions over encrypted data [11, 19, 23, 24]. We use an instance of FHE called TFHE [13] in this work. We briefly summarize TFHE below; see [13] for a detailed exposition.

We are concerned with the following two-party secure computation, where the involved parties are a client (called Alice) and a server (called Bob): 1) Alice generates the keys used during computation; 2) Alice encrypts her plaintext messages into ciphertexts with her keys; 3) Alice sends the ciphertexts to Bob; 4) Bob conducts computation over the received ciphertexts and obtains the encrypted result without decryption; 5) Bob sends the encrypted results to Alice; 6) Alice decrypts the received results and obtains the results in plaintext.

Keys. There are three types of keys in TFHE: secret key $\mathrm {SK}$, public key $\mathrm {PK}$, and bootstrapping key $\mathrm {BK}$. All of them are generated by Alice. $\mathrm {PK}$ is used to encrypt plaintext messages into ciphertexts, and $\mathrm {SK}$ is used to decrypt ciphertexts into plaintexts. Alice keeps $\mathrm {SK}$ private, i.e., the key is known only to herself but not to Bob. In contrast, $\mathrm {PK}$ is public and also known to Bob. $\mathrm {BK}$ is generated from $\mathrm {SK}$ and can be safely shared with Bob without revealing $\mathrm {SK}$. $\mathrm {BK}$ allows Bob to evaluate the homomorphic operations (defined later) over the ciphertext.

Ciphertexts. Using the public key, Alice can generate three kinds of ciphertexts (Table 2): TLWE (Torus Learning With Errors), TRLWE (Torus Ring Learning With Errors), and TRGSW (Torus Ring Gentry-Sahai-Waters). Homomorphic operations provided by TFHE are defined over each of the specific ciphertexts. We note that different ciphertexts have different data structures, and their conversion can be time-consuming. Table 2 shows one such example.

In TFHE, different types of ciphertexts represent different plaintext messages. A TLWE ciphertext represents a Boolean value. In contrast, TRLWE represents a vector of Boolean values of length N, where N is a TFHE parameter. We can regard a TRLWE ciphertext as a vector of TLWE ciphertexts, and the conversion between a TRLWE ciphertext and a TLWE one is relatively easy. A TRGSW ciphertext also represents a Boolean value, but its data structure is quite different from TLWE, and the conversion from TLWE to TRGSW is slow.

TFHE provides different encryption and decryption functions for each type of ciphertext. We write $\text {Enc}(x)$ for a ciphertext of a plaintext x; $\text {Dec}(c)$ for the plaintext message for the ciphertext c. We abuse these notations for all three types of ciphertexts.

Besides, TFHE supports trivial samples of TRLWE. A trivial sample of TRLWE has the same data structure as a TRLWE ciphertext but is not encrypted, i.e., anyone can tell the plaintext message represented by the trivial sample. We denote by $\textsc {Trivial} (n)$ a trivial sample of TRLWE whose plaintext message is $(b_1,b_2,\dots ,b_{N})$, where each $b_{i}$ is the i-th bit in the binary representation of n.

Homomorphic Operations. TFHE provides homomorphic operations, i.e., operations over ciphertexts without decryption. Among the operators supported by TFHE [13], we use the following ones.

• CMux $(d,\mathbf {c_{{true}}},\mathbf {c_{{false}}})\text { : }\textsf {TRGSW} \times \textsf {TRLWE} \times \textsf {TRLWE} \rightarrow \textsf {TRLWE}$

  Given a TRGSW ciphertext d and TRLWE ciphertexts $\mathbf {c}_{\text {true}}, \mathbf {c}_{\text {false}}$, CMux outputs a TRLWE ciphertext $\mathbf {c}_{\text {result}}$ such that $\text {Dec}(\mathbf {c}_{\text {result}})=\text {Dec}(\mathbf {c}_\text {true})$ if $\text {Dec}(d)=1$, and otherwise, $\text {Dec}(\mathbf {c}_{\text {result}})=\text {Dec}(\mathbf {c}_\text {false})$.

• LookUp $(\{\mathbf {c}_i\}_{i=1}^{2^n}, \{d_i\}_{i=1}^n)\text { : }(\textsf {TRLWE})^{2^n}\times (\textsf {TRGSW})^n\rightarrow \textsf {TRLWE}$

  Given TRLWE ciphertexts $\mathbf {c}_1,\mathbf {c}_2,\dots ,\mathbf {c}_{2^n}$ and TRGSW ciphertexts $d_1,d_2,\dots ,d_{n}$, LookUp outputs a TRLWE ciphertext $\mathbf {c}$ such that $\text {Dec}(\mathbf {c}) = \text {Dec}(\mathbf {c}_k)$ and $k = \sum _{i=1}^{n} 2^{i-1}\times \text {Dec}(d_i)$.

• SampleExtract $(k, \mathbf {c})\text { : } \mathbb {N}\times \textsf {TRLWE} \rightarrow \textsf {TLWE}$

  Let $\text {Dec}(\mathbf {c}) = (b_1,b_2,\dots ,b_{N})$. Given $k < N$ and a TRLWE ciphertext $\mathbf {c}$, SampleExtract outputs a TLWE ciphertext c where $\text {Dec}(c)=b_{k+1}$.

Intuitively, CMux can be regarded as a multiplexer over TRLWE ciphertexts with TRGSW selector input. The operation LookUp regards $\mathbf {c}_1,\mathbf {c}_2,\dots ,\mathbf {c}_{2^n}$ as encrypted entries composing a LookUp Table (LUT) of depth n and $d_1,d_2,\dots ,d_{n}$ as inputs to the LUT. Its output is the entry selected by the LUT. LookUp is constructed by $2^n-1$ CMux arranged in a tree of depth n. SampleExtract outputs the k-th element of $\mathbf {c}$ as TLWE. Notice that all these operations work over ciphertexts without decrypting them.

Noise and Operations for Noise Reduction. In generating a TFHE ciphertext, we ensure its security by adding some random numbers called noise. An application of a TFHE operation adds noise to its output ciphertext; if the noise in a ciphertext becomes too large, the TFHE ciphertext cannot be correctly decrypted. There is a special type of operation called bootstrapping¹ [23], which reduces the noise of a TFHE ciphertext.

• Bootstrapping $_{\mathrm {BK}}(c)\text { : } \textsf {TLWE} \rightarrow \textsf {TRLWE}$

  Given a bootstrapping key $\mathrm {BK}$ and a TLWE ciphertext c, Bootstrapping outputs a TRLWE ciphertext $\mathbf {c}$ where $\text {Dec}(\mathbf {c}) = (b_1, b_2, \dots , b_{N})$ and $b_1 = \text {Dec}(c)$. Moreover, the noise of $\mathbf {c}$ becomes a constant that is determined by the parameters of TFHE and is independent of c.

• CircuitBootstrapping $_{\mathrm {BK}}(c)\text { : } \textsf {TLWE} \rightarrow \textsf {TRGSW}$

  Given a bootstrapping key $\mathrm {BK}$ and a TLWE ciphertext c, CircuitBootstrapping outputs a TRGSW ciphertext d where $\text {Dec}(d) = \text {Dec}(c)$. The noise of d becomes a constant that is determined by the parameters of TFHE and is independent of c.

These bootstrapping operations are used to keep the noise of a TFHE ciphertext small enough to be correctly decrypted. Bootstrapping and CircuitBootstrapping are almost two and three orders of magnitude slower than CMux, respectively [13].

Parameters for TFHE. There are many parameters for TFHE, such as the length N of the message of a TRLWE ciphertext and the standard deviation of the probability distribution from which a noise is taken. Certain properties of TFHE depend on these parameters. These properties include the security level of TFHE, the number of TFHE operations that can be applied without bootstrapping ensuring correct decryption, and the time and the space complexity of each operation. The complete list of TFHE parameters is presented in the full version [4].

We remark that we need to determine the TFHE parameters before performing any TFHE operation. Therefore, we need to know the number of applications of homomorphic operations without bootstrapping in advance, i.e., the homomorphic circuit depth must be determined a priori.

2.3 Leveled Homomorphic Offline Algorithm

Chillotti et al. [13] proposed an offline algorithm to evaluate a DFA over TFHE ciphertexts (Algorithm 1). Given a DFA M and TRGSW ciphertexts $d_1, d_2, \dots , d_{n}$, Algorithm 1 returns a TLWE ciphertext c satisfying $\text {Dec}(c) = M(\text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_{n}))$. For simplicity, for a state q of M, we write $M^i(q)$ for $M(q,\text {Dec}(d_i)\text {Dec}(d_{i+1})\dots \text {Dec}(d_n))$.

In Algorithm 1, we use a TRLWE ciphertext $\mathbf {c}_{i,q}$ whose first element represents $M^{i+1}(q)$, i.e., whether we reach a final state by reading $\text {Dec}(d_{i+1})\text {Dec}(d_{i+2})\dots \text {Dec}(d_n)$ from q. We abuse this notation for $i=n$, i.e., the first element of $\mathbf {c}_{n,q}$ represents if $q \in F$. In Lines 1 and 2, we initialize $\mathbf {c}_{n,q}$; For each $q\in Q$, we let $\mathbf {c}_{n,q}$ be $\textsc {Trivial} (1)$ if $q \in F$; otherwise, we let $\mathbf {c}_{n,q}$ be $\textsc {Trivial} (0)$. In Lines 3–5, we construct $\mathbf {c}_{i-1,q}$ inductively by feeding each monitored ciphertext $d_i$ to CMux from tail to head. Here, $\mathbf {c}_{i-1,q}$ represents $M^i(q)$ because of $M^{i}(q) = M^{i+1}(\delta (q,\text {Dec}(d_i)))$. We note that for the efficiency, we only construct $\mathbf {c}_{i-1,q}$ for the states reachable from $q_0$ by $i-1$ transitions. In Line 6, we extract the first element of $\mathbf {c}_{0,q_0}$, which represents $M^1(q_0)$, i.e., $M(\text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_n))$.

Theorem 1

(Correctness [13, Thm. 5.4]). Given a binary DFA M and TRGSW ciphertexts $d_1,d_2,\dots ,d_n$, if c in Algorithm 1 can be correctly decrypted, Algorithm 1 outputs c satisfying $\text {Dec}(c)=M(\text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_n))$.    $\square$

Complexity Analysis. The time complexity of Algorithm 1 is determined by the number of applications of CMux, which is O(n|Q|). Its space complexity is O(|Q|) because we can use two sets of |Q| TRLWE ciphertexts alternately for $\mathbf {c}_{2j-1,q}$ and $\mathbf {c}_{2j,q}$ (for $j\in \mathbb {N}^+$).

Shortcomings of Algorithm 1. We cannot use Algorithm 1 under an online setting due to two reasons. Firstly, Algorithm 1 is a leveled homomorphic algorithm, i.e., the maximum length of the ciphertexts that Algorithm 1 can handle is determined by TFHE parameters. This is because Algorithm 1 does not use Bootstrapping, and if the monitored ciphertexts are too long, the result c cannot be correctly decrypted due to the noise. This is critical in an online setting because we do not know the length n of the monitored ciphertexts in advance, and we cannot determine such parameters appropriately.

Secondly, Algorithm 1 consumes the monitored ciphertext from back to front, i.e., the last ciphertext $d_{n}$ is used in the beginning, and $d_{1}$ is used in the end. Thus, we cannot start Algorithm 1 before the last input is given.

3 Online Algorithms for Running DFA Obliviously

In this section, we propose two online algorithms that run a DFA obliviously. As a preparation for these online algorithms, we also introduce a fully homomorphic offline algorithm based on Algorithm 1.

3.1 Preparation: Fully Homomorphic Offline Algorithm (Offline)

As preparation for introducing an algorithm that can run a DFA under an online setting, we enhance Algorithm 1 so that we can monitor a sequence of ciphertexts whose length is unknown a priori. Algorithm 2 shows our fully homomorphic offline algorithm (Offline), which does not require TFHE parameters to depend on the length of the monitored ciphertexts. The key difference lies in Lines 6–9 (the red lines) of Algorithm 2. Here, for every $I_{\mathrm {boot}}$ consumption of the monitored ciphertexts, we reduce the noise by applying Bootstrapping to the ciphertext $\mathbf {c}_{i,j}$ representing a state of the DFA. Since the amount of the noise accumulated in $\mathbf {c}_{i,j}$ is determined only by the number of the processed ciphertexts, we can keep the noise levels of $\mathbf {c}_{i,j}$ low and ensure that the monitoring result c is correctly decrypted. Therefore, by using Algorithm 2, we can monitor an arbitrarily long sequence of ciphertexts as long as the interval $I_{\mathrm {boot}}$ is properly chosen according to the TFHE parameters. We note that we still cannot use Algorithm 2 for online monitoring because it consumes the monitored ciphertexts from back to front.

3.2 Online Algorithm 1: Reverse

To run a DFA online, we modify Offline so that the monitored ciphertexts are consumed from front to back. Our main idea is illustrated in Fig. 2b: we reverse the DFA M beforehand and feed the ciphertexts $d_1, d_2,\dots ,d_n$ to the reversed DFA $M^{\mathrm {R}}$ serially from $d_1$ to $d_n$.

Algorithm 3 shows the outline of our first online algorithm (Reverse) based on the above idea. Reverse takes the same inputs as Offline: a DFA M, TRGSW ciphertexts $d_1, d_2, \dots , d_n$, a bootstrapping key $\mathrm {BK}$, and a positive integer $I_{\mathrm {boot}}$ indicating the interval of bootstrapping. In Line 1, we construct the minimum DFA $M^{\mathrm {R}}$ that satisfies, for any $w=\sigma _1\sigma _2\dots \sigma _{k} \in \mathbb {B}^*$, we have $M^{\mathrm {R}}(w) = M(w^R)$, where $w^R=\sigma _{k}\dots \sigma _1$. We can construct such a DFA by reversing the transitions and by applying the powerset construction and the minimization algorithm.

In the loop from Lines 4-12, the reversed DFA $M^{\mathrm {R}}$ consumes each monitored ciphertext $d_i$, which corresponds to the loop from Lines 3-9 in Algorithm . The main difference lies in Line 5 and 8: Algorithm 3 applies CMux and Bootstrapping to all the states of $M^{\mathrm {R}}$, while Algorithm 2 only considers the states reachable from the initial state. This is because in online monitoring, we monitor a stream of ciphertexts without knowing the number of the remaining ciphertexts, and all the states of the reversed DFA $M^{\mathrm {R}}$ are potentially reachable from the initial state $q_0^{\mathrm {R}}$ by the reversed remaining ciphertexts $d_n,d_{n-1},\dots ,d_{i+1}$ because of the minimality of $M^{\mathrm {R}}$.

Theorem 2

Given a binary DFA M, TRGSW ciphertexts $d_1,d_2,\dots ,d_n$, a bootstrapping key $\mathrm {BK}$, and a positive integer $I_{\mathrm {boot}}$, for each $i \in \{1,2,\dots ,n\}$, if $c_i$ in Algorithm 3 can be correctly decrypted, Algorithm 3 outputs $c_i$ satisfying $\text {Dec}(c_i) = M(\text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_{i}))$.

Proof (sketch). SampleExtract and Bootstrapping in Line 9 and 10 do not change the decrypted value of $c_i$. Therefore, $\text {Dec}(c_i)=M^{\mathrm {R}}(\text {Dec}(d_{i})\dots \text {Dec}(d_1))$ for $i \in \{1,2,\dots , n\}$ by Theorem 1. As $M^{\mathrm {R}}$ is the reversed DFA of M, we have $\text {Dec}(c_i) = M^{\mathrm {R}}(\text {Dec}(d_{i})\dots \text {Dec}(d_1)) = M(\text {Dec}(d_1)\dots \text {Dec}(d_{i})).$    $\square$

3.3 Online Algorithm 2: Block

A problem of Reverse is that the number of the states of the reversed DFA can explode exponentially due to powerset construction (see Sect. 3.4 for the details). Another idea of an online algorithm without reversing a DFA is illustrated in Fig. 2c: we split the monitored ciphertexts into blocks of fixed size $B$ and process each block in the same way as Algorithm 2. Intuitively, for each block $d_{1 + (i - 1) \times B}, d_{2 + (i - 1) \times B},\dots ,d_{B+ (i - 1) \times B}$ of ciphertexts, we compute the function $T_{i}:Q \rightarrow Q$ satisfying $T_{i}(q) = \delta (q, d_{1 + (i - 1) \times B}, d_{2 + (i - 1) \times B},\dots ,d_{B+ (i - 1) \times B})$ by a variant of Offline, and keep track of the current state of the DFA after reading the current prefix $d_{1}, d_{2},\dots ,d_{B+ (i - 1) \times B}$.

Algorithm 4 shows the outline of our second online algorithm (Block) based on the above idea. Algorithm 4 takes a DFA M, TRGSW ciphertexts $d_1,d_2,\dots ,d_n$, a bootstrapping key $\mathrm {BK}$, and an integer $B$ representing the interval of output. To simplify the presentation, we make the following assumptions, which are relaxed later: 1) $B$ is small, and a trivial TRLWE sample can be correctly decrypted after $B$ applications of CMux; 2) the size |Q| of the states of the DFA M is smaller than or equal to $2^{N-1}$, where N is the length of TRLWE.

The main loop of the algorithm is sketched on Lines 2–19. In each iteration, we consume the i-th block consisting of $B$ ciphertexts, i.e., $d_{(i-1)B+1}, \dots , d_{(i-1)B+ B}$. In Line 3, we compute the set $S_{i + 1} = \{s^{i+1}_1, s^{i+1}_2, \dots , s^{i+1}_{|S_\text {next}|}\}$ of the states reachable from $q_0$ by reading a word of length $i \times B$.

In Lines 4–10, for each $q \in Q$, we construct a ciphertext representing $T_{i}(q)$ by feeding the current block to a variant of Offline. More precisely, we construct a ciphertext $\mathbf {c}^{T_i}_{0,q}$ representing the pair of the Boolean value showing if $T_i(q) \in F$ and the state $T_i(q) \in Q$. The encoding of such a pair in a TRLWE ciphertext is as follows: the first element shows if $T_i(q) \in F$ and the other elements are the binary representation of $j \in \mathbb {N}^+$, where j is such that $s^{i+1}_{j} = T_i(q)$.

In Lines 11–17, we construct the ciphertext $\mathbf {c}^\text {cur}_{i+1}$ representing the state of the DFA M after reading the current prefix $d_{1}, d_{2},\dots ,d_{B+ (i - 1) \times B}$. If $|S_i|=1$, since the unique element q of $S_i$ is the only possible state before consuming the current block, the state after reading it is T(q). Therefore, we let $\mathbf {c}^\text {cur}_{i+1} = \mathbf {c}^{T_i}_{0,q}$.

Otherwise, we extract the ciphertext representing the state q before consuming the current block, and let $\mathbf {c}^\text {cur}_{i+1} = \mathbf {c}^{T_i}_{0,q}$. Since the $\mathbf {c}^\text {cur}_i$ (except for the first element) represents q (see Line 7), we extract them by applying SampleExtract (Line 15) and convert them to TRGSW by applying CircuitBootstrapping (Line 16). Then, we choose $\mathbf {c}^{T_i}_{0,q}$ by applying LookUp and set it to $\mathbf {c}^\text {cur}_{i+1}$.

The output after consuming the current block, i.e., $M(\text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_{(i-1)B+B}))$ is stored in the first element of the TRLWE ciphertext $\mathbf {c}^\text {cur}_{i+1}$. It is extracted by applying SampleExtract in Line 18 and output in Line19.

Theorem 3

Given a binary DFA M, TRGSW ciphertexts $d_1,d_2,\dots ,d_n$, a bootstrapping key $\mathrm {BK}$, and a positive integer $B$, for each $i \in \{1,2,\dots , \lfloor n/B\rfloor \}$, if $c_i$ in Algorithm 4 can be correctly decrypted, Algorithm 4 outputs a TLWE ciphertext $c_i$ satisfying $\text {Dec}(c_i) = M(\text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_{i \times B}))$.

Proof (sketch)

Let $q^i$ be $\delta (q_0, \text {Dec}(d_1)\text {Dec}(d_2)\dots \text {Dec}(d_{i \times B}))$. It suffices to show that, for each iteration i in Line 2, $\text {Dec}(\mathbf {c}_{i+1}^\text {cur})$ represents a pair of the Boolean value showing if $q^i\in F$ and the state $q^i\in Q$ in the above encoding format. This is because $c_i$ represents the first element of $\mathbf {c}_{i+1}^\text {cur}$. Algorithm 4 selects $\mathbf {c}_{i+1}^\text {cur}$ from $\{\mathbf {c}_{0,q}^{T_i}\}_{q\in S_i}$ in Line 12 or Line 17. By using a slight variant of Theorem 1 in Lines 11–17, we can show that $\mathbf {c}_{0,q}^{T_i}$ represents if $T^i(q)\in F$ and the state $T^i(q)$. Therefore, the proof is completed by showing $\text {Dec}(\mathbf {c}_{i+1}^\text {cur}) = \text {Dec}(\mathbf {c}_{0,q^{i-1}}^{T_i})$.

We prove $\text {Dec}(\mathbf {c}_{i+1}^\text {cur}) = \text {Dec}(\mathbf {c}_{0,q^{i-1}}^{T_i})$ by induction on i. If $i = 1$, $|S_i| = 1$ holds, and by $q^{i-1} \in S_{i}$, we have $\text {Dec}(\mathbf {c}_{i+1}^\text {cur}) = \text {Dec}(\mathbf {c}_{0,q^{i-1}}^{T_i})$. If $i > 1$ and $|S_i| = 1$, $\text {Dec}(\mathbf {c}_{i+1}^\text {cur}) = \text {Dec}(\mathbf {c}_{0,q^{i-1}}^{T_i})$ holds similarly. If $i > 1$ and $|S_i| > 1$, by induction hypothesis, $\text {Dec}(\mathbf {c}_{i}^\text {cur})$ represents if $T_{i-1}(q^{i-2}) = q^{i-1}\in F$ and the state $q^{i-1}$. By construction in Line 16, $\text {Dec}(d'_l)$ is equal to the l-th bit of $(j-1)$, where j is such that $s_j^i = q^{i-1}$. Therefore, the result of the application of LookUp in Line 17 is equivalent to $\mathbf {c}_{0,s^{i}_{j}}^{T_i} (= \mathbf {c}_{0,q^{i-1}}^{T_i})$, and we have $\text {Dec}(\mathbf {c}_{i+1}^\text {cur}) = \text {Dec}(\mathbf {c}_{0,q^{i-1}}^{T_i})$.    $\square$

We note that Block generates output for every B monitored ciphertexts while Reverse generates output for every monitored ciphertext.

We also remark that when $B=1$, Block consumes every monitored ciphertext from front to back. However, such a setting is slow due to a huge number of CircuitBootstrapping operations, as pointed out in Sect. 3.4.

Relaxations of the Assumptions. When $B$ is too large, $\mathbf {c}_{0,q}^{T_i}$ may not be correctly decrypted. We can relax this restriction by inserting Bootstrapping just after Line 10, which is much like Algorithm 2. When the size |Q| of the states of the DFA M is larger than $2^{N-1}$, we cannot store the index j of the state using one TRLWE ciphertext (Line 7). We can relax this restriction by using multiple TRLWE ciphertexts for $\mathbf {c}_{0,q}^{T_i}$ and $\mathbf {c}_{i+1}^{\mathrm {cur}}$.

Table 3. Complexity of the proposed algorithms with respect to the number |Q| of the states of the DFA and the size $|\phi |$ of the LTL formula. For Block, we show the complexity before the relaxation.

3.4 Complexity Analysis

Table 3 summarizes the complexity of our algorithms with respect to both the number |Q| of the states of the DFA and the size $|\phi |$ of the LTL formula. We note that, for Block, we do not relax the above assumptions for simplicity. Notice that the number of applications of the homomorphic operations is linear to the length n of the monitored ciphertext. Moreover, the space complexity is independent of n. This shows that our algorithms satisfy the properties essential to good online monitoring; 1) they only store the minimum of data, and 2) they run quickly enough under a real-time setting [5].

The time and the space complexity of Offline and Block are linear to |Q|. Moreover, in these algorithms, when the i-th monitored ciphertext is consumed, only the states reachable by a word of length i are considered, which often makes the scalability even better. In contrast, the time and the space complexity of Reverse is exponential to |Q|. This is because of the worst-case size of the reversed DFA due to the powerset construction. Since the size of the reversed DFA is usually reasonably small, the practical scalability of Reverse is also much better, which is observed through the experiments in Sect. 5.

For Offline and Block, |Q| is doubly exponential to $|\phi |$ because we first convert $\phi$ to an NFA (one exponential) and then construct a DFA from the NFA (second exponential). In contrast, for Reverse, it is known that we can construct a reversed DFA for $\phi$ of the size of at most singly exponential to $|\phi |$ [15]. Note that, in a practical scenario exemplified in Sect. 5, the size of the DFA constructed from $\phi$ is expected to be much smaller than the worst one.

4 Oblivious Online LTL Monitoring

In this section, we formalize the scheme of oblivious online LTL monitoring. We consider a two-party setting with a client and a server and refer to the client and the server as Alice and Bob, respectively. Here, we assume that Alice has private data sequence $w = \sigma _1\sigma _2\dots \sigma _n$ to be monitored where $\sigma _i\in 2^{\mathrm {AP}}$ for each $i \ge 1$. Meanwhile, Bob has a private LTL formula $\phi$. The purpose of oblivious online LTL monitoring is to let Alice know if $\sigma _1\sigma _2\dots \sigma _{i}\models \phi$ for each $i \ge 1$, while keeping the privacy of Alice and Bob.

4.1 Threat Model

We assume that Alice is malicious, i.e., Alice can deviate arbitrarily from the protocol to try to learn $\phi$. We also assume that Bob is honest-but-curious, i.e., Bob correctly follows the protocol, but he tries to learn w from the information he obtains from the protocol execution. We do not assume that Bob is malicious in the present paper; a protocol that is secure against malicious Bob requires more sophisticated primitives such as zero-knowledge proofs and is left as future work.

Public and Private Data. We assume that the TFHE parameters, the parameters of our algorithms (e.g., $I_{\mathrm {boot}}$ and B), Alice’s public key $\mathrm {PK}$, and Alice’s bootstrapping key $\mathrm {BK}$ are public to both parties. The input w and the monitoring result are private for Alice, and the LTL formula $\phi$ is private for Bob.

4.2 Protocol Flow

The protocol flow of oblivious online LTL monitoring is shown in Fig. 3. It takes $\sigma _1,\sigma _2,\dots ,\sigma _n$, $\phi$, and $b\in \mathbb {B}$ as its parameters, where b is a flag that indicates the algorithm Bob uses: Reverse ($b=0$) or Block ($b=1$). After generating her secret key and sending the corresponding public and bootstrapping key to Bob (Lines 1–3), Alice encrypts her inputs into ciphertexts and sends the ciphertexts to Bob one by one (Lines 5–8). In contrast, Bob first converts his LTL formula $\phi$ to a binary DFA M (Line 4). Then, Bob serially feeds the received ciphertexts from Alice to Reverse or Block (Line 9) and returns the encrypted output of the algorithm to Alice (Lines 10–13).

Note that, although the alphabet of a DFA constructed from an LTL formula is $2^{\mathrm {AP}}$ [36], our proposed algorithms require a binary DFA. Thus, in Line 4, we convert the DFA constructed from $\phi$ to a binary DFA M by inserting auxiliary states. Besides, in Line 6, we encode an observation $\sigma _i \in 2^{\mathrm {AP}}$ by a sequence $\sigma '_i{:}{=}({\sigma '}_i^1, {\sigma '}_i^2, \dots , {\sigma '}_i^{|AP|}) \in \mathbb {B}^{|AP|}$ such that $p_j \in \sigma _i$ if and only if ${\sigma '}_i^j$ is true, where $\mathrm {AP}= \{p_1, \dots , p_{|\mathrm {AP}|}\}$. We also note that, taking this encoding into account, we need to properly set the parameters for Block to generate an output for each $|\mathrm {AP}|$-size block of Alice’s inputs, i.e., B is taken to be equal to $|\mathrm {AP}|$.

Here, we provide brief sketches of the correctness and security analysis of the proposed protocol. See the full version [4] for detailed explanations and proofs.

Fig. 3.

Protocol of oblivious online LTL monitoring.

Correctness. We can show that Alice obtains correct results in our protocol directly by Theorem 2 and Theorem 3.

Security. Intuitively, after the execution of the protocol described in Fig. 3, Alice should learn $M(\sigma '_1\cdot \sigma '_2\cdots \sigma '_{i})$ for every $i\in \{1,2,\dots ,n\}$ but nothing else. Besides, Bob should learn the input size n but nothing else.

Privacy for Alice. We observe that Bob only obtains $\text {Enc}({\sigma '}_i^j)$ from Alice for each $i\in \{1,2,\dots ,n\}$ and $j\in \{1,2,\dots ,|\mathrm {AP}|\}$. Therefore, we need to show that Bob learns nothing from the ciphertexts generated by Alice. Since TFHE provides IND-CPA security [7], we can easily guarantee the client’s privacy for Alice.

Privacy for Bob. The privacy guarantee for Bob is more complex than that for Alice. Here, Alice obtains $\sigma '_1,\sigma '_2,\dots ,\sigma '_n$ and the results $M(\sigma '_1\cdot \sigma '_2\cdots \sigma '_{i})$ for every $i\in \{1,2,\dots ,n\}$ in plaintext. In the protocol (Fig. 3), Alice does not obtain $\phi ,M$ themselves or their sizes, and it is known that a finite number of checking M(w) cannot uniquely identify M if any additional information (e.g., |M|) is not given [2, 32]. Thus, it is impossible for Alice to identify M (or $\phi$) from the input/output pairs.

Nonetheless, to fully guarantee the model privacy of Bob, we also need to show that, when Alice inspects the result ciphertext $c'$, it is impossible for Alice to know Bob’s specification, i.e., what homomorphic operations were applied by Bob to obtain $c'$. A TLWE ciphertext contains a random nonce and a noise term. By randomizing c properly in Line 11, we ensure that the random nonce of $c'$ is not biased [34]. By assuming SRL security [10, 21] over TFHE, we can ensure that there is no information leakage regarding Bob’s specifications through the noise bias. A more detailed discussion is in the full version [4].

5 Experiments

We experimentally evaluated the proposed algorithms (Reverse and Block) and protocol. We pose the following two research questions:

RQ1.:

Are the proposed algorithms scalable with respect to the size of the monitored ciphertexts and that of the DFA?

RQ2.:

Are the proposed algorithms fast enough in a realistic monitoring scenario?

RQ3.:

Does a standard IoT device have sufficient computational power acting as a client in the proposed protocol?

To answer RQ1, we conducted an experiment with our original benchmark where the length of the monitored ciphertexts and the size of the DFA are configurable (Sect. 5.1). To answer RQ2 and RQ3, we conducted a case study on blood glucose monitoring; we monitored blood glucose data obtained by simglucose² against specifications taken from [12, 38] (Sect. 5.2). To answer RQ3, we measured the time spent on the encryption of plaintexts, which is the heaviest task for a client during the execution of the online protocol.

We implemented our algorithms in C++20. Our implementation is publicly available³. We used Spot [17] to convert a safety LTL formula to a DFA. We also used a Spot’s utility program ltlfilt to calculate the size of an LTL formula⁴. We used TFHEpp [30] as the TFHE library. We used $N=1024$ as the size of the message represented by one TRLWE ciphertext, which is a parameter of TFHE. The complete TFHE parameters we used are shown in the full version [4].

For RQ1 and RQ2, we ran experiments on a workstation with Intel Xeon Silver 4216 (3.2 GHz; 32 cores and 64 threads in total), 128 GiB RAM, and Ubuntu 20.04.2 LTS. We ran each instance of the experiment setting five times and reported the average. We measured the time to consume all of the monitored ciphertexts in the main loop of each algorithm, i.e., in Lines 4–12 in Reverse and in Lines 2–19 in Block.

For RQ3, we ran experiments on two single-board computers with and without Advanced Encryption Standard (AES) [14] hardware accelerator. ROCK64 has ARM Cortex A53 CPU cores (1.5 GHz; 4 cores) with AES hardware accelerator and 4 GiB RAM. Raspberry Pi 4 has ARM Cortex A72 CPU cores (1.5 GHz; 4 cores) without AES hardware accelerator and 4 GiB RAM.

Fig. 4.

Experimental results of $M_m$. The left figure shows runtimes when the number of states (i.e., m) is fixed to 500, while the right one is when the number of monitored ciphertexts (i.e., n) is fixed to 50000.

5.1 RQ1: Scalability

Experimental Setup. In the experiments to answer RQ1, we used a simple binary DFA $M_m$, which accepts a word w if and only if the number of the appearance of 1 in w is a multiple of m. The number of the states of $M_m$ is m.

Our experiments are twofold. In the first experiment, we fixed the DFA size m to 500 and increased the size n of the input word w from 10000 to 50000. In the second experiment, we fixed $n=50000$ and changed m from 10 to 500. The parameters we used are $I_{\mathrm {boot}}= 30000$ and $B = 150$.

Results and Discussion. Figure 4 shows the results of the experiments. In the left plot of Fig. 4, we observe that the runtimes of both algorithms are linear to the length of the monitored ciphertexts. This coincides with the complexity analysis in Sect. 3.4.

In the right plot of Fig. 4, we observe that the runtimes of both algorithms are at most linear to the number of the states. For Block, this coincides with the complexity analysis in Sect. 3.4. In contrast, this is much more efficient than the exponential complexity of Reverse with respect to |Q|. This is because the size of the reversed DFA does not increase.

In both plots of Fig. 4, we observe that Reverse is faster than Block. Moreover, in the left plot of Fig. 4, the curve of Block is steeper than that of Reverse. This is because 1) the reversed DFA $M_m^{\mathrm {R}}$ has the same size as $M_m$, 2) CircuitBootstrapping is about ten times slower than Bootstrapping, and 3) $I_{\mathrm {boot}}$ is much larger than $B$.

Overall, our experiment results confirm the complexity analysis in Sect. 3.4. Moreover, the practical scalability of Reverse with respect to the DFA size is much better than the worst case, at least for this benchmark. Therefore, we answer RQ1 affirmatively.

5.2 RQ2 and RQ3: Case Study on Blood Glucose Monitoring

Experimental Setup. To answer RQ2, we applied Reverse and Block to the monitoring of blood glucose levels. The monitored values are generated by simulation of type 1 diabetes patients. We used the LTL formulae in Table 4. These formulae are originally presented as signal temporal logic [28] formulae [12, 38], and we obtained the LTL formulae in Table 4 by discrete sampling.

To simulate blood glucose levels of type 1 diabetes patients, we adopted simglucose, which is a Python implementation of UVA/Padova Type 1 Diabetes Simulator [29]. We recorded the blood glucose levels every one minute⁵ and encoded each of them in nine bits. For $\psi _1,\psi _2,\psi _4$, we used 720 min of the simulated values. For $\phi _1,\phi _4,\phi _5$, we used seven days of the values. The parameters we used are $I_{\mathrm {boot}}= 30000$, $B = 9$.

To answer RQ3, we encrypted plaintexts into TRGSW ciphertexts 1000 times using two single-board computers (ROCK64 and Raspberry Pi 4) and reported the average runtime.

Results and Discussion (RQ2). The results of the experiments are shown in Table 5. The result for $\psi _4$ with Reverse is missing because the reversed DFA for $\psi _4$ is too huge, and its construction was aborted due to the memory limit.

Although the size of the reversed DFA was large for $\psi _1$ and $\psi _2$, in all the cases, we observe that both Reverse and Block took at most 24 s to process each blood glucose value on average. This is partly because |Q| and $|Q^R|$ are not so large in comparison with the upper bound described in Sect. 3.4, i.e., doubly or singly exponential to $|\phi |$, respectively. Since each value is recorded every one minute, at least on average, both algorithms finished processing each value before the next measured value arrived, i.e., any congestion did not occur. Therefore, our experiment results confirm that, in a practical scenario of blood glucose monitoring, both of our proposed algorithms are fast enough to be used in the online setting, and we answer RQ2 affirmatively.

We also observe that average runtimes of $\psi _1,\psi _2,\psi _4$ and $\phi _1,\phi _4,\phi _5$ with Block are comparable, although the monitoring DFA of $\psi _1,\psi _2,\psi _4$ are significantly larger than those of $\phi _1,\phi _4,\phi _5$. This is because the numbers of the reachable states during execution are similar among these cases (from 1 up to 27 states). As we mentioned in Sect. 3.4, Block only considers the states reachable by a word of length i when the i-th monitored ciphertext is consumed, and thus, it ran much faster even if the monitoring DFA is large.

Table 4. The safety LTL formulae used in our experiments. $\psi _1,\psi _2,\psi _4$ are originally from [12], and $\phi _1$, $\phi _4$, and $\phi _5$ are originally from [38].

Table 5. Experimental results of blood glucose monitoring, where Q is the state space of the monitoring DFA and $Q^{\mathrm {R}}$ is the state space of the reversed DFA.

Results and Discussion (RQ3). It took 40.41 and 1470.33 ms on average to encrypt a value of blood glucose (i.e., nine bits) on ROCK64 and Raspberry Pi 4, respectively. Since each value is sampled every one minute, our experiment results confirm that both machines are fast enough to be used in an online setting. Therefore, we answer RQ3 affirmatively.

We also observe that encryption on ROCK64 is more than 35 times faster than that on Raspberry Pi 4. This is mainly because of the hardware accelerator for AES, which is used in TFHEpp to generate TRGSW ciphertexts.

6 Conclusion

We presented the first oblivious online LTL monitoring protocol up to our knowledge. Our protocol allows online LTL monitoring concealing 1) the client’s monitored inputs from the server and 2) the server’s LTL specification from the client. We proposed two online algorithms (Reverse and Block) using an FHE scheme called TFHE. In addition to the complexity analysis, we experimentally confirmed the scalability and practicality of our algorithms with an artificial benchmark and a case study on blood glucose level monitoring.

Our immediate future work is to extend our approaches to LTL semantics with multiple values, e.g., LTL${}_3$ [6]. Extension to monitoring continuous-time signals, e.g., against an STL [28] formula, is also future work. Another future direction is to conduct a more realistic case study of our framework with actual IoT devices.