Walnut: A low-trust trigger-action platform

Sandy Schoettler

Andrew Thompson

Rakshith Gopalakrishna

Trinabh Gupta

University of California, Santa Barbara

Abstract

Trigger-action platforms are a new type of system that con-

nect IoT devices with web services. For example, the popular

IFTTT platform can connect Fitbit with Google Calendar

to add a bedtime reminder based on sleep history. However,

these platforms present conﬁdentiality and integrity risks as

they run on public cloud infrastructure and compute over

sensitive user data. This paper describes the design, imple-

mentation, and evaluation of Walnut, a low-trust trigger-action

platform that mimics the functionality of IFTTT, while en-

suring conﬁdentiality of data and correctness of computation,

at a low resource cost. The key enabler for Walnut is a new

two-party secure computation protocol that (i) efﬁciently per-

forms strings substitutions, which is a common computation

in trigger-action platform workloads, and (ii) replicates com-

putation over heterogeneous trusted-hardware machines from

different vendors to ensure correctness of computation out-

put as long as one of the machines is not compromised. An

evaluation of Walnut demonstrates its plausible deployability

and low overhead relative to a non-secure baseline—3.6

CPU and 4.3

in network for all but a small percentage of

programs.

1 Introduction

The platforms that manage heterogeneous Internet of Things

(IoT) devices have become mainstream [

]. However, these platforms undermine user conﬁdentiality

and integrity as they compute over sensitive user data. There-

fore, a relevant question is: how can we build a system that

can manage IoT devices without incurring the security risks?

To expand on the motivation above, consider the case of

trigger-action platforms [

]. They connect IoT

devices with web services through simple customizable pro-

grams. For example, a user can set up programs to sync Fitbit

with iOS Health [

], adjust home temperature when they

request an Uber to take them home [

], tweet Instagram

photos [

], turn off oven if the smoke alarm detects an emer-

gency [

], and even move money from checking to savings

depending on daily step count [45].

Besides providing connectivity across devices and online

services, trigger-action platforms are easy to use. They run in

the cloud and require no local, in-home installation or mainte-

nance. Furthermore, they allow a user to go ofﬂine indeﬁnitely

after setting up a program. Finally, their interfaces are so sim-

ple that an average internet user can specify programs for

them with only a few clicks. Indeed, popular trigger-action

Student authors contributed equally to the paper.

platforms like IFTTT [

] run tens of millions of programs

daily on behalf of their users [58, 59].

However, this connectivity and convenience comes at a cost

(

2). When users opt to run programs on these platforms, they

must provide unobstructed access to sensitive data needed by

the programs (and generated or consumed by the devices or

services). Furthermore, the users assume that the platforms

correctly perform actions on their behalf: adjust thermostat to

the right temperature, post the intended tweet, do not tamper

with health data, and remove the right amount of money from

the checking account.

The security risks affect not just the users: when platform

providers operate on user data, they become liable for protect-

ing it. Indeed, under new privacy regulations in California and

EU [

], a business can be subject to a class action lawsuit

or large ﬁne (for example, up to 4 percent of global annual

revenue) for data breaches and misuse.

Given the popularity of trigger-action platforms, there is

prior work targeting improved security for them [

However, as we discuss later (

9), these works provide con-

ﬁdentiality or integrity exclusively, and suffer from a funda-

mental weakness that shifts security risks from the platform

to the connected services.

In this paper, we address these limitations and demonstrate

that we do not need to compromise signiﬁcantly on security to

support the automation provided by trigger-action platforms.

We present Walnut, a trigger-action platform that provides the

same functionality as IFTTT, but with much stronger conﬁ-

dentiality and integrity protection. Furthermore, this added

protection does not affect the security at the connected ser-

vices, and comes at a modest resource cost.

To begin with, Walnut splits the platform into two parts

that run in separate administrative domains (Microsoft Azure

and IBM Cloud) such that no part can access sensitive

data (

3.1). To obtain such a split, Walnut employs a two-

party secure computation protocol (2PC) called Yao’s garbled

circuits [

], which allows two parties to perform arbitrary

computation on their secret inputs without revealing their in-

puts to each other. Yao’s protocol is powerful as it supports

arbitrary computation but it is also expensive in terms of CPU

time and network transfers.

Walnut makes two observations. First, typical programs on

trigger-action platforms perform simple computations: they

either pass a sensitive string from one device or service to

another without modiﬁcation, or substitute strings from a

dictionary of sensitive strings into a user-supplied template

string. Second, the names of the keys in the dictionary are

publicly known. Based on these observations, Walnut designs

arXiv:2009.12447v1 [cs.CR] 25 Sep 2020

a custom two-party secure computation protocol for the typi-

cal trigger-action platform programs. Walnut’s protocol leaks

coarse-grained information such as the approximate positions

in the template string where the strings from the dictionary

get substituted. However, it signiﬁcantly reduces overhead

relative to Yao’s protocol; in particular, it eliminates network

overhead between the two parties in the protocol (§4).

The 2PC protocol described so far allows Walnut’s plat-

form to compute over sensitive data but does not prevent the

platform from deviating from the protocol and producing arbi-

trary program output. To efﬁciently add integrity guarantees,

Walnut extends the protocol to use trusted-hardware machines

such as those with Intel SGX [

] and AMD SEV [

] ca-

pabilities. These machines provide a trusted execution en-

vironment (TEE) that can load and execute a computation

such that an external entity cannot tamper with its execution.

However, a limitation of using TEEs is that they introduce

a large trusted computing base (TCB), consisting of both a

software component and a hardware component.

The software part can be moved out of the TCB by formally

verifying that the software meets its required speciﬁcation [

]. However, the hardware itself (the root of trust)

can be tampered, for example, through physical attacks [

32, 33, 52].

Walnut addresses this limitation by employing multiple,

heterogeneous TEEs from different vendors. In particular, it

runs a copy of the 2PC protocol described above over three

pairs of TEEs, where each counterpart in a pair resides in

one of the two domains (for example, Microsoft Azure or

IBM Cloud). Walnut’s protocol does not guarantee an output;

however, if it does produce an output, then the output is

correct as long as one of the TEEs is not compromised (

5).

Recently, Chandran et al. [

] explored this idea of multiple

TEEs to obtain theoretical feasibility results in cryptography;

however, this idea has not been explored in practical systems.

Besides using the two techniques above, Walnut’s 2PC pro-

tocol composes cryptographic primitives such as end-to-end

encryption, digital signatures, and hash-chaining of OAuth

authentication tokens. The latter, in particular, allows a user

of Walnut to go ofﬂine indeﬁnitely after uploading a program

to run on the Walnut platform (§6).

We have implemented (

7) and evaluated (

8) a prototype

of Walnut. Our prototype runs on Microsoft Azure and IBM

Cloud. For sparsely-used programs for which Walnut resorts

to using Yao’s protocol, it incurs a high CPU and network

overhead: 54

for CPU and 1883

for the network relative

to a non-secure baseline that mimics IFTTT. However, for

typical programs that run on IFTTT (a manual inspection of

50 most popular programs per the dataset of Mi et al. [

]

reveals that 98% of them fall in this category), Walnut incurs

3.6

CPU and 4.3

network overhead relative to the non-

secure baseline. We also implemented 30 programs from

IFTTT (15 from the set of 50 most popular ones per Mi et

al. [

], and 15 selected randomly) on Walnut, demonstrating

IF sleep is under a target duration THEN

add a reminder to Google Calendar.

Input

title: "Slept 6 hrs.

Sleep early"

Service: Fitbit

Sleep under a

target duration

OAuth

Get daily activity

summary

Input

target:

"8 hrs"

Output

actual:

"6 hrs"

Service: Google

Add a reminder

to Calendar

OAuth

Applet

IFTTT platform (runs on AWS)

Fitbit device

Figure 1: High-level architecture of IFTTT [

] in the context

of a program (applet) that connects Fitbit service to Google

calendar service.

that Walnut is plausibly deployable.

Walnut’s limitations include coarse-grained leakage from

its customized 2PC protocol. Nevertheless, we believe Walnut

is useful: it provides a beneﬁt to both users and platform

providers, as they can enjoy trigger-action automation with

signiﬁcant improvement in data conﬁdentiality and integrity,

at low resource cost.

2 Overview of IFTTT (IF-This-Then-That)

Walnut aims to mimic IFTTT’s functionality as IFTTT is

a popular trigger-action platform [

]. This

section gives an overview of IFTTT and describes the conﬁ-

dentiality and integrity risks it presents.

Figure 1 depicts IFTTT’s architecture, which consists of

three key components: services, platform, and applets.

Services are either IoT device management services such as

the Fitbit service or online-only web-services such as Google

calendar. These services expose user information and provide

an ability to update that information through HTTP-based

RESTful APIs. For example, the Fitbit service exposes an

API that returns the sleep duration of a user. Similarly, the

Google calendar service exposes an API to add a reminder to

a user’s calendar.

The IFTTT platform runs in the public cloud (AWS cur-

rently). It aggregates APIs from all services and presents them

to applets. It is also responsible for executing these applets.

Applets are programs that stitch together two service APIs.

They are the core abstraction that IFTTT exposes. For exam-

ple, the “When you sleep less than the desired amount, add

a reminder on your calendar to go to bed early tomorrow”

applet connects the sleep duration API from Fitbit with the

add reminder API from Google calendar. An applet contains

a TypeScript code that takes the output of the ﬁrst API and

manipulates it before feeding into the second API. For in-

stance, the applet depicted in Figure 1 takes the user’s sleep

duration string “6 hrs” returned by the Fitbit API and adds

it to the title of the reminder. An applet also contains OAuth

authentication tokens [

] that allow the platform to access

the APIs on user behalf.

Conﬁdentiality and integrity risks.

IFTTT acts as a delega-

tee and runs applets on user behalf; this arrangement naturally

creates both conﬁdentiality and integrity risks. In particular,

when a user creates an applet and loads it to the IFTTT plat-

form, or when the IFTTT platform executes the applet, the

platform learns sensitive information such as the APIs the

user intends to use, the parameters the user wants to send to

the APIs, and the information returned by the APIs. Similarly,

the IFTTT platform creates integrity risks because it may not

run an applet as intended. For instance, it may set an incorrect

time for reminder in the Fitbit and Google calendar example

discussed above. In other examples, it may cause more dam-

age: turn oven on instead of off, move an incorrect amount

of money from a user’s checking to savings account, drop

malware into user’s dropbox account, etc.

The conﬁdentiality and integrity risks described above are

signiﬁcant; however, the current design of the IFTTT platform

and the connected services exacerbates them. The connected

services give out OAuth access tokens with broad scope, so

that a user can authenticate with a service once and use the

token across applets that call different APIs at the service [

–

]. Thus, if the platform misbehaves, it can create malicious

applets using the (broad) OAuth tokens.

Thus, our goal is to design mechanisms that address these

risks, that is, enable the IFTTT platform provider to keep user

data conﬁdential while operating on it as intended by the user,

at low resource costs (CPU, network, etc.). We are not saying

that the IFTTT platform provider is inherently untrustworthy.

However, the platform provider runs the platform on a public

cloud. Besides, there are many cases of both internal and

external adversaries, such as rogue system administrators and

hackers, that can get into cloud infrastructure and steal and

tamper with user information [

]. On top of

that, the platform provider is incentivized to reduce risk for

user data due to the risk of signiﬁcant ﬁnes and lawsuits under

modern privacy regulation [1, 2].

3 Overview of Walnut

3.1 Architecture

Figure 2 shows Walnut’s architecture. Walnut has the same

key components as IFTTT, namely the platform, services, and

applets, but makes modiﬁcations, particularly, to the platform

and the services.

Walnut’s platform runs over two servers, S

and S

, in sep-

arate administrative domains such as Microsoft Azure and

IBM Cloud. Each server is logically centralized but physically

distributed; it contains trusted-hardware machines from dif-

ferent vendors (denoted as “TEE-A”, “TEE-B”, and “TEE-C”

in Figure 2) and general-purpose compute machines (labeled

collectively as M

and M

in Figure 2).

on IBM Cloud

Crypto

General

purpose

machine

TEE-A

TEE-B

TEE-C

on Microsoft Azure

TEE-A

TEE-B

TEE-C

General

purpose

machine

ProofProof

Walnut platform

User

Install

applet

Call trigger

API

Call action

API

Gen. input

to action

function

Service Service

0 1

Figure 2: Walnut’s architecture. Solid, dotted, dashed, and

dashed-with-dots arrows respectively depict computation per-

formed during setup, trigger-polling, action-generation, and

action-execution phases of Walnut’s protocol.

The services implement the HTTP APIs. Today, they send

or receive plaintext data (over secure channels) to or from

the platform. Therefore, some change is necessary to sup-

port a secure Walnut platform. Walnut expects these services

to implement logic for basic cryptographic primitives such

as encryption, signatures, and secret-sharing (described be-

low), and to be aware of and hold public keys for Walnut’s

two servers and their TEEs. This logic is agnostic of the

API implementation, and thus can be implemented once and

distributed to all the services (for example, by the Walnut

platform provider).

In Walnut, as in IFTTT, the applet is the core programming

abstraction. Walnut does not make any change to this core

abstraction. Each applet consists of URLs for two APIs: a

trigger API and an action API. We denote the inputs to the

APIs as trigInp and actInp, respectively, and the output from

the trigger API as trigOut (the action API does not produce

an output). Each of trigInp, trigOut, and actInp is a set of key-

value pairs. ﬁlterCode is the code component of the applet

that produces actInp based on trigOut.

Walnut’s protocol to delegate execution of an applet to Wal-

nut’s platform has four phases: setup, trigger-polling, action-

generation, and action-execution.

• Setup.

This phase (marked

in Figure 2) runs once per

applet. During this phase, the user creates the applet App

and gives its parts to the two servers: part

App

to S

and

part

App

to S

. Each part contains signed ciphertexts or

secret-shares of the sensitive applet data. Secret-sharing

refers to the technique of splitting a secret s into two strings,

(s)

and sh

(s)

, such that each string appears uniformly

random, but sh

(e)

⊕ sh

(e)

= e.

• Trigger-polling.

As in IFTTT, this phase (marked

Figure 2) runs periodically (every 15 minutes) or in re-

sponse to a real-time notiﬁcation from the service imple-

menting the trigger API. In this phase, server S

calls the

trigger API in the applet. In return, server S

for each

b ∈ {0, 1} gets a signed secret-share of trigOut.

• Action-generation.

This phase (marked

in Figure 2)

follows the trigger-polling phase. In this phase, each Wal-

nut server uses its outputs from the two phases above, and

runs a cryptographic protocol with the other server to ob-

tain its secret-share of the input to the action API. That is,

obtains sh

(actInp)

. Server S

also generates a proof that

it computed sh

(actInp)

correctly. This phase uses the TEE

machines at the two servers.

• Action-execution.

Finally, in the action-execution phase

(marked

in Figure 2), the two servers send their output

from the action-generation phase to the service implement-

ing the action API, who performs checks on the proofs,

merges the shares of the API input, and executes the API.

3.2 Threat model and security deﬁnitions

We consider two settings for Walnut, passive and active, de-

pending on the power of the adversary. In the passive setting,

the adversary is honest-but-curious, meaning that it follows

the protocol description but tries to infer sensitive user data by

inspecting protocol messages. In this setting, Walnut uses only

the general-purpose machines at S

, which are collectively

denoted as M

for b

∈ {

0, 1

}

. The adversary can compromise

one of M

for some b ∈ {0, 1}.

In the active setting, the adversary is malicious and can ar-

bitrarily deviate from the protocol. In this setting, each server

uses three types of TEEs (made by three different vendors)

besides the general-purpose machines; we denote S

’s three

types of TEEs by T

(i)

for i

∈ {

0, 1, 2

}

. The adversary can

compromise one of M

for b

∈ {

0, 1

}

, and at most two of

(0)

, T

(1)

and T

(2)

We deﬁne security notions for the two settings separately.

Deﬁnition 3.1

(Passive security)

A passive Walnut scheme

consisting of setup, trigger-polling, action-generation, and

action-execution phases is said to be

-secure if for any

honest-but-curious (passive) probabilistic polynomial time

(PPT) adversary

corrupting M

for some b

∈ {

0, 1

}

, for

a leakage function

, for every large enough security pa-

rameter

, there exists a PPT simulator

Sim

with access

to the leakage function, such that the output distribution of

the simulator is computationally indistinguishable from the

adversary’s view in the real protocol.

Deﬁnition 3.2

(Active security)

An active Walnut scheme

consisting of setup, trigger-polling, action-generation, and

action-execution phases is said to be

-secure with abort if,

for any malicious (active) probabilistic polynomial time (PPT)

adversary

corrupting M

, T

(i)

, T

(j)

for some b

∈ {

0, 1

}

and

i, j

∈ {

0, 1, 2

}

, with black-box access to TEE T

(k)

implement-

ing functionality

(k)

for k

∈ {

0, 1, 2

}

and k

i, k

for a leakage function

, for every large enough security pa-

rameter

, there exists a PPT simulator

Sim

with access

to the leakage function, such that the output distribution of

the simulator is computationally indistinguishable from the

adversary’s view in the real protocol.

Essentially, the deﬁnitions say that the view of the adver-

sary in an execution of Walnut’s protocol can be simulated by

knowing just the inputs to the simulator, which is deﬁned by

the leakage function. Furthermore, the protocol aborts if the

adversary in the active setting deviates from the protocol.

For Walnut, the leakage function is deﬁned as

App

)

which equals

{K(

App

)

App

)

App

)}

App

)

equals

{

, K

. . .

, K

}

, where where m is the number of key-

value pairs in the actInp parameter to action API, and K

{

key

, key

. . .

key

}

contains the key names of key-value

pairs in trigOut that go into computing the i-th key-value

pair of actInp.

App

)

equals

{

pos

, pos

. . .

, pos

}

, where

pos

= {

index

, index

. . .

, index

}

is the set of positions in

the i-th key-value pair in actInp where the key-value pairs in

trigOut get inserted.

App

)

is the ﬁlterCode for the applet

and the URLs of trigger and action APIs.

3.3 Key techniques

Walnut’s protocol consisting of the four phases (setup, trigger-

polling, action-generation, action-execution) and meeting the

security deﬁnitions stated above uses three key techniques.

Tailored 2PC for IFTTT-like applets.

Walnut’s protocol,

in the action-generation phase, uses a tailored two-party se-

cure computation (2PC) cryptographic sub-protocol to enable

its servers to obtain secret-shares of actInp. Walnut’s 2PC

protocol is tailored to the common ﬁlterCode that generates

actInp ﬁelds via string substitutions, for instance, by sub-

stituting the value of duration in the template string “Slept

{{

duration

}}

. Sleep early.” Although Walnut’s protocol leaks

a small amount of information, captured in the leakage func-

tion above, it is signiﬁcantly more efﬁcient than a general-

purpose 2PC protocol [80] (§4).

Proof replication across heterogeneous TEEs.

Walnut, dur-

ing the action-generation phase, uses trusted hardware ma-

chines to generate hardware attestations (which we call proofs

for simplicity) that the code to generate action API input is

executed inside a trusted execution environment (TEE). How-

ever, relative to a solution that would use a single TEE for

proof generation, Walnut replicates proof generation over

heterogeneous TEEs such that as long as one TEE works

correctly, an adversary cannot pass a proof check and result

in an incorrect invocation of the action API (§5).

Chaining of OAuth tokens.

Walnut, as in IFTTT, ensures

that a user can go ofﬂine after executing the setup phase.

To enable this behavior, Walnut creates signed tuples of the

expirable OAuth token supplied by the user during the setup

phase and fresh OAuth tokens generated by the services (

6).

Besides these three techniques, Walnut uses standard cryp-

tographic primitives such as encryption, hashing, and signa-

tures. The next three sections (

4–

6) dive into the details

of Walnut’s protocol. We begin by making a simplifying as-

sumption that the OAuth tokens do not expire. Under this

assumption, we ﬁrst present Walnut’s design that meets the

security deﬁnition for the passive setting described above

Walnut’s protocol for the passive security setting

•

This protocol has four parties: a user, Walnut’s platform consisting of machines M

and M

in separate administrative domains,

a trigger service TS, and an action service AS. The protocol allows the user to install an applet and the platform to execute it.

• The protocol assumes that each entity has a (public, private) key pair (pk

, sk

), for p ∈ {User, M

, M

, TS, AS}.

Setup phase

(Encrypt OAuth tokens) The user receives OAuth access tokens at

TS and at

AS from TS and AS, respectively. The user

encrypts these tokens, that is, computes C

at-TS

← Enc(pk

, at-TS) and C

at-AS

← Enc(pk

, at-AS).

2. (Encrypt trigInp) The user encrypts the trigInp input parameter, that is, computes C

trigInp

← Enc(pk

, trigInp).

3. (Secret-share actInp) For each key-value pair (k, v) in install-time value of actInp, the user does the following:

(a)

Splits v into blocks (t

. . .

, t

) at spaces and and punctuation marks. For instance, splits “Slept

{{

duration

}}

. Sleep early”

into (“Slept”, “ ”, “{{duration}}”, “.”, “ ”, “Sleep”, “ ”, “early”).

(b) For each t

, if t

is like “{{key-name}}”, sets sh

)

= t

. Else, secret-shares t

into sh

)

and sh

)

, s.t. sh

)

⊕ sh

)

= t

(actInp)

[k] = (sh

)

, . . . , sh

)

The user sends App

= {

T, A

, fc

}

to M

, where T equals

(triggerEndpoint

, C

at-TS

, C

trigInp

)

, A

equals

(actionEndpoint, C

at-AS

, sh

(actInp)

), and fc is the applet ﬁlterCode.

Trigger-polling phase

5. (Call trigger API) Machine M

sends T to the trigger service TS (whose name is in triggerEndpoint URL in T).

(Generate shares of trigOut) TS decrypts and checks the OAuth token, executes the trigger API, and generates trigOut. Then,

for each (k, v) in trigOut, TS generates sh

(trigOut)

[k] following step 3 above.

7. TS sends sh

(trigOut)

to M

Action-generation phase

(Generates shares of runtime value of actInp) M

generates sh

(actInp)

← GenerateAI(

(trigOut)

, sh

(actInp)

, fc

)

. GenerateAI

further calls either Yao’s 2PC protocol or Walnut’s string substitution function (Figure 4) depending on ﬁlterCode.

Action-execution phase

9. M

sends (actionEndpoint, C

at-AS

, sh

(actInp)

) to AS, who reconstructs actInp, validates at-AS, and executes the action API.

Figure 3: Walnut’s protocol for the passive setting to execute an applet. This protocol does not include concatenation and padding

of blocks, which is described separately in text. This protocol further calls Yao’s protocol [80] or the function in Figure 4.

(

4). This design does not require the TEE machines. We

then extend the design and present a protocol that meets the

security deﬁnition for the active setting (

5). Finally, we relax

the simplifying assumption on OAuth token expiry (§6).

4 Design for passive security

Figure 3 shows Walnut’s protocol for the passive security

setting discussed in the previous section (

3.2). This protocol

is optimized, in terms of performance, for the common types

of applets on IFTTT that perform simple substitutions: set

the value of a key-value pair in actInp by replacing parts of a

template string with values from trigOut. We brieﬂy describe

each phase of the protocol below; the protocol ﬁgure contains

precise details.

Setup phase.

First, the user obtains OAuth tokens for the two

services and encrypts them with their public keys (step 1 in

Figure 3). Second, the user encrypts trigInp as a single blob

with the trigger service’s public key (step 2 in Figure 3). Third,

the user splits the setup-time values in actInp into blocks and

secret-shares each block (step 3b in Figure 3).

Trigger-polling.

In this phase, M

sends encrypted blob of

trigInp to the trigger service implementing the trigger API.

The trigger service generates secret-shares of trigOut in the

same way as the user generates shares of actInp in the setup

step (step 6 in Figure 3). For instance, if one of the trigOut

key-value pairs is ‘duration’: ‘6 hrs’, then the trigger service

partitions the value ‘6 hrs’ into blocks (“6”, “ ”, “hrs”) and

secret-shares them.

Action-generation.

and M

call Yao’s garbled circuits

protocol to run the applets’s ﬁlterCode over shares of blocks

from trigOut and (setup-time value of) actInp; the call to

Yao happens inside the GenerateAI function in step 8 in Fig-

ure 3. Yao’s protocol is general-purpose and can handle any

arbitrary ﬁlterCode. However, when the ﬁlterCode involves

simple string substitutions, M

and M

locally run the function

string sub

shown in Figure 4. The

string sub

procedure

returns a single block for each key-value pair of actInp.

Action-execution.

and M

send their outputs from action-

generation phase along with OAuth tokens to the action ser-

# 'actInp_shr' is a list of block shares from user.

# shr(pad(str)) denotes a share of a padded block.

actInp_shr = [{"type": TEXT, "value": shr(

pad("Slept") + pad(" "))},

{"type": FIELD, "key-name": "duration"},

{"type": TEXT, "value": shr(pad(".") + pad(" ")

+ pad("Sleep") + pad(" ") + pad("early"))}]

# Input 'trigOut_shr' from the trigger service.

# Func. maps trigOut key-names to shares of actInp.

def string_sub(trigOut_shr, actInp_shr):

output = []

for part in actInp_shr:

if part.type == FIELD: # lookup key-name

output += trigOut_shr[part.key-name]

else:

output += part.value

return "".join(output) # concatenate the blocks

Figure 4: Walnut’s custom function for string substitution.

This function assumes that secret-shares of block of strings

are both padded and concatenated (explained further in text).

vice, who reconstructs actInp, checks the OAuth tokens, and

executes the action API.

Concatenation and padding.

One issue with the protocol

described above is that it reveals to Walnut the length of

each block in the strings in trigOut and actInp. Walnut mit-

igates this leak by concatenation and padding. First, both

the user and the trigger service apply padding to each block

separately. This padding is conﬁgurable: each block can be

padded to a pre-determined maximum size, or each block can

be padded to the next higher size from a set of allowed pre-

determined sizes (for example, multiples of ﬁve, or powers

of two). Second, the user and the trigger service concatenate

padded adjacent blocks that do not contain key names. For

instance, (“Slept”, “ ”, “

{{

duration

}}

”, “.”, “ ”, “Sleep”, “ ”,

“early”) becomes three blocks (“Slept XXXX, “

{{

duration

}}

”,

“.XXXX XXXXSleep XXXXearly”), and (“6”, “ ”, “hrs”) be-

comes a single block (“6XXXX XXXXhrsXX”), where “X”

denotes padding.

Security analysis.

The protocol described above meets the

passive security deﬁnition in

3.2; Appendix C.2 contains

a proof. But, at a high-level, the protocol encrypts OAuth

tokens and trigInp with the trigger service’s public key so that

they remain hidden from both Walnut servers. The protocol

also only reveals, to each Walnut server, secret-shares of large

blocks that are formed by padding and concatenating smaller

blocks; this leakage is captured in the deﬁnition in §3.2.

Notably, unlike prior work [

], Walnut’s protocol en-

sures that the trigger and action service learn strictly the same

information as they do in IFTTT. In particular, the trigger

service handles request to the trigger API; it learns neither

about the action API nor how trigOut is used to invoke the

action API. Similarly, the action service learns only the act-

Inp parameter needed to execute the action API. Speciﬁcally,

padding both trigOut and actInp in the same way ensures

that the action service cannot outrightly distinguish parts of

a string that come from trigOut versus setup-time value of

actInp (just how it is in IFTTT). Thus, Walnut does not in-

crease data liability at the services—in line with the data

minimization or least privilege principle [1, 2, 22, 68].

Performance analysis.

The setup phase runs once and thus

its cost gets amortized across multiple executions of an applet.

Here, we focus on the costs of the other phases.

In the trigger-polling phase, the use of encryption and

secret-sharing adds CPU and network overhead at the platform

and the services. However, this overhead is small, as encryp-

tion and secret-sharing are cheap operations which take less

than a millisecond (§8).

In the action-generation phase, if the protocol invokes Yao’s

protocol, then the CPU and network overhead for Walnut’s

two servers increases signiﬁcantly, as Yao represents the ﬁl-

terCode as a low-level, verbose Boolean circuit (a network

of Boolean gates such as AND and XOR), and incurs cryp-

tographic operations for each gate in the circuit [

However, majority of the time, Walnut calls the

string sub

protocol, which performs cheap local computation. Indeed,

in the top-50 popular applets in the dataset of Mi et al. [

only one uses custom ﬁlterCode while the others use string

substitution. Similarly, in the 15 randomly selected applets

we implement (§8.4), none require custom ﬁlterCode.

The action-execution phase is also efﬁcient like the trigger-

polling phase as it uses the cheap decryption and secret-

sharing operations.

5 Design for active security

Walnut’s protocol in the previous section assumes a passive

(honest-but-curious) adversary who can monitor protocol mes-

sages but not tamper with protocol execution. In particular,

the protocol in Figure 3 assumes:

(i)

machine M

does not corrupt the trigger part of the applet

T before sending it to trigger service (step 5 in Figure 3),

(ii)

and M

do not tamper with trigOut or the applet parts

that feed into action-generation (step 8 in Figure 3),

(iii) M

and M

run GenerateAI correctly,

(iv)

and M

do not tamper with the message sent to the

action service (step 10 in Figure 3), and

(v)

machines M

and M

do not replay requests to action

service (requests to a trigger service are idempotent).

One way to relax these assumptions is to extend the pro-

tocol with zero-knowledge proofs [

] that allow

proving the correctness of code execution without reveal-

ing the sensitive data that the code is operating on. However,

these protocols are expensive. Instead, Walnut uses digital sig-

natures and trusted execution environments (TEEs)—recall,

in the active setting, each Walnut server has three TEE ma-

chines (

3.1). At a high-level, signatures enable services to

verify that that the information they are receiving has not

Walnut’s protocol for the active security setting

• This protocol assumes each Walnut server S

has a general-purpose machine M

and three TEEs T

(0)

, T

(1)

, and T

(2)

•

The protocol assumes that each entity has a key-pair that it uses to sign messages and allow others to verify signed messages.

Setup phase

1. The user runs steps 1 to 3 in Figure 3 to create App

= {T, A

, fc}, for all b ∈ {0, 1}.

(Sign request to trigger API) The user appends a unique identiﬁer TID to T, and asks TS to sign T. The user obtains

← Sign(sk

, T).

3. The user adds σ

and public key of trigger service pk

to App

, and sends App

to each of M

, T

(0)

, T

(1)

, and T

(2)

Trigger-polling phase

4. (Call trigger API) M

sends (App

.T, App

.σ

) to trigger service TS.

(Generate signed shares of trigOut) TS veriﬁes

and runs step 6 in Figure 3 to get sh

(trigOut)

. TS then samples a unique

identiﬁer RID for response, constructs tout

← (

RID, TID, sh

(trigOut)

)

, and computes

tout

← Sign(

, tout

) ∀

∈ {

0, 1

}

6. TS sends (tout

, σ

tout

) to M

Action-generation phase

7. (Generate signed actInp shares) M

sends (tout

, σ

tout

) to each TEE T

(i)

, who does the following:

(a) Checks tout

is from the correct TS and for the correct trigger API:

i. Asserts Verify(App

.pk

, tout

, σ

tout

) is True.

ii. Asserts TID in tout

equals App

.T.TID.

(b) (Generate actionFields shares) Runs step 8 in Figure 3 with T

(i)

1−b

to generate sh

(actInp

)

(c)

(Sign request to action service) Constructs ain

(i)

← (

tout

.RID,

actionEndpoint

, C

at-AS

, sh

(actInp

)

, where actionEndpoint

and C

at-AS

are part of A

in App

. Then, T

(i)

computes proof-T

(i)

← Sign(sk

(i)

, ain

(i)

), gives (proof-T

(i)

, ain

(i)

) to M

Action-execution phase

8. (Send request) M

sends ain

(i)

from any one of its TEEs to AS. M

also sends proof-T

(i)

for all i ∈ {0, 1, 2}.

9. (Check proofs) For all b ∈ {0, 1}, and for all i ∈ {0, 1, 2}, AS asserts Verify(pk

(i)

, ain

(i)

, proof-T

(i)

) equals True.

10.

AS checks RID in ain

(i)

and ain

(i)

is equal and unique, reconstructs actInp, validates OAuth token, and executes action API.

Figure 5: Walnut’s protocol for the active security setting. This protocol uses the TEE machines at Walnut’s two servers.

been tampered. Meanwhile, TEEs such as Intel SGX [

AMD SEV [

], ARM TrustZone [

], provide a tamper-proof

sandbox for executing computation. Figure 5 shows Walnut’s

protocol that incorporates these integrity primitives; we now

brieﬂy describe each phase and reﬂect on the protocol’s secu-

rity guarantees and performance.

Setup and trigger-polling.

The main difference in these

phases (relative to the passive security protocol) is the ad-

dition of signatures (steps 2 and 5 in Figure 5) to the input

and output of the trigger API. Besides signatures, these phases

add unique IDs, particularly to the output of the trigger API.

Action-generation.

This phase uses the TEE machines at

the two servers. Each TEE (i) matches the response from

the trigger service to the correct applet (step 7a in Figure 5),

(ii) runs the GenerateAI function, and (iii) signs its part of

the request to the action service (step 7c in Figure 5). This

signature becomes a proof that the action service should act on

the request. However, since all but one of the TEE machines

may be compromised (

3.2), the action service acts on the

request only if proofs from all the TEEs are valid.

Action-execution.

The action service checks the proofs, en-

sures the uniqueness of the unique identiﬁer in the request,

and executes the action API.

Security analysis.

The protocol described in Figure 5 meets

the active security deﬁnition in

3.2. Appendix C.3 contains

a proof. But, brieﬂy, the cryptographic binding guarantees of

digital signatures ensures that the messages the services re-

ceive are not tampered. Besides, the use of TEEs and equality

checks ensures that actInp are computed correctly. Finally,

the use of unique IDs ensures that requests to action service

are not replayed.

Performance analysis.

As with the protocol for passive se-

curity, the cost of setup phase gets amortized across many

invocations of an applet. Therefore, we focus on the costs of

the other phases.

The protocol adds (relative to the passive security protocol)

low CPU and network overhead in the trigger-polling phase,

for two reasons. First, signature generation and checking takes

less than a millisecond (

8), and each signature is 64 bytes

with elliptic-curve cryptography. Second, the trigger service

sends its output (step 6 in Figure 5) once to each server; in

contrast, a naive design would make the trigger service send

a copy of trigOut to each TEE separately.

In the action-generation phase, the main overhead is due

to the replication of GenerateAI function three times on the

three TEEs (step 7b in Figure 5). When GenerateAI further

calls Yao’s protocol, this increase is signiﬁcant as Yao’s CPU

and network costs are high. However, when GenerateAI calls

Walnut’s efﬁcient

string sub

procedure, then the impact on

the protocol is small.

In the action-execution phase, the protocol adds low CPU

and network overhead. Again, the protocol sends only one

copy of actInp from each server to the action service. Each

TEE does send a separate signature but signatures are small

in size (64 bytes each) and signature veriﬁcation takes less

than a millisecond of CPU time.

6 Supporting OAuth tokens with expiry

So far, we have assumed that OAuth tokens do not expire

(the user puts tokens in applet during the setup phase and

goes ofﬂine). However, in practice, some IFTTT applets use

OAuth that do expire. This section ﬁrst quickly reviews how

expirable tokens work, and then describe Walnut’s protocol.

Expirable tokens in OAuth protocol.

The OAuth protocol

uses two tokens: an access token and a refresh token. Each

token has an expiration time. The holder of these tokens

includes the access token in regular GET and POST requests

to HTTP endpoints. However, if the access token is expired,

the endpoint returns a HTTP 401 unauthorized error. Then,

the token holder sends a refresh request to an OAuth endpoint

consisting of both the access token and the refresh token; if

the refresh token has not expired, the endpoint returns a new

access token and refresh token [38].

Walnut’s protocol to support OAuth token refresh.

One

way for Walnut to support expirable tokens is to use the

TEEs at the two servers, who could initiate the refresh tokens

request and update the tokens in an applet. However, Walnut

uses a protocol that avoids the use of TEEs. Walnut’s high-

level idea is to use a signed chain of encrypted tokens—to

link the original user-supplied tokens with new tokens.

Assume that time is split into epochs, beginning with the

0-th epoch. Also, let

be the valid access token in the k-th

epoch, and deﬁne

(Enc(

pk,

kat

)

as the token-chain

for the same epoch; here, encryption is under the key of the

entity issuing the tokens (a trigger or action service) and

is a signature by the same entity over the ciphertext. Then,

during a regular HTTP request to a trigger or action API in

the k-th epoch (steps 4 and 8 in Figure 5), machines M

and

at Walnut’s platform append the k-th token-chain to the

request. When the service receives the request, it veriﬁes the

signature, and matches the

part of the chain to the original

user-supplied access token in the request. If there is a match,

then the service replaces the original token in the request with

(this replacement is done in the API-agnostic logic added

to the services; §3.1).

A question is: how does Walnut’s machines M

and M

obtain the token-chain for the k-th epoch? The user supplies

the chain for the 0-th epoch, that is,

(Enc(

pk,

kat

)

as part of the applet during setup. To enable M

and M

get the chain for the k-th epoch, Walnut extends the refresh

token request to the OAuth endpoint. As mentioned above

in the background, normally the token holder sends the re-

fresh and access tokens for the k-th epoch and receives re-

fresh and access tokens for the

(

)

-th epoch. In Walnut,

includes the token-chain for the the k-th epoch, that is,

(Enc(

pk,

kat

)

, in the refresh request. The service ver-

iﬁes that the token

in the chain matches the token in the

regular part of the refresh request, and sends the chain for the

(k + 1)-th epoch, that is, (Enc(pk, at

k+1

kat

), σ

k+1

Security analysis.

Walnut’s protocol with the extension de-

scribed above meets the active security deﬁnition in

3.2.

Appendix C.3 contains a proof. But, brieﬂy, Walnut’s proto-

col keeps tokens (both original and in the chain) for all epochs

encrypted with the services’ keys. Also, the Walnut platform

makes a successful request to a trigger and action API if it

has a valid chain and a valid (but expired) user-supplied token.

Finally, Walnut’s servers get a chain for a new epoch only if

they possess the expiring (but valid) chain.

Performance analysis.

The protocol extension affects mainly

the trigger-polling and action-execution phases. In particular,

the addition of token-chain to the requests to the trigger and

action APIs (steps 4 and 8 in Figure 5) adds CPU at the

services to verify the chain, and network transfers between

the platform and services to transport the chain. Meanwhile,

the refresh tokens request (to get a chain for a new epoch)

adds token chains but is made infrequently.

7 Implementation

We have implemented a prototype of Walnut (

3.1,

4–

6).

Our prototype is written in Python and C. The Python part

implements a web server that interacts with the user and the

services. The C part implements RPC servers inside TEEs to

execute the action-generation step of Walnut’s protocol. Both

parts build on existing libraries and frameworks, including

Flask [

] for the web server, MongoDB [

] for storing

applets, Authlib [

] for the OAuth protocol, OblivC [

]

for Yao’s garbled circuits, OpenSSL [

] for cryptographic

functions, and SGX-LKL [

] as a library operating system.

Walnut’s implementation over existing libraries is 2128 lines

For applets with custom ﬁlterCode (≈1-2%), Walnut increases

platform-side CPU and network costs by 54× and 1883× over a

non-secure baseline. However, for common applets, Walnut

increases these costs by 3.6× and 4.3×.

§8.1

For all applets, Walnut increases CPU and network costs at trigger

and action services by up to 3.2

and 2.52

, respectively, relative

to a non-secure baseline.

§8.2

Walnut’s dollar cost for running the common applets is 3.74

of a

non-secure baseline.

§8.3

One can program existing IFTTT applets on Walnut with ease.

§8.4

Figure 6: Summary of main evaluation results.

machine vendor CPUs RAM SGX location

B1ms MS Azure 1 2 GB No SF, CA

DC4s v2 MS Azure 4 16 GB Yes Blue Ridge, VA

B1.1x2 IBM Cloud 1 2 GB No SJ, CA

bm IBM Cloud 4 16 GB Yes SJ, CA

n1-std-4 Google Cloud 4 15 GB No The Dalles, OR

Figure 7: Machines used in Walnut’s experiments.

of Python and 2721 lines of C.

8 Evaluation

Walnut’s evaluation answers the following questions:

What are Walnut’s overheads relative to a non-secure

baseline that mimics IFTTT?

How much overhead do Walnut techniques (

4—

incur?

3. For what kinds of applets is Walnut practical?

Figure 6 summarizes our evaluation results.

Method and setup.

We compare Walnut to the following

baseline systems. NoSec is our Python-based reference imple-

mentation of IFTTT (IFTTT itself is closed-source). NoSec

uses Flask as a web server, MongoDB as a data store for

applets, and the Python requests framework [

] for HTTP

requests. W-Yao, W-C, and W-I are intermediate baselines

between NoSec and Walnut. W-Yao implements Walnut’s

protocol for the passive security setting. It provides conﬁ-

dentiality but no integrity guarantees. Further, it uses Yao’s

protocol only for secure computation (

4). W-C builds on W-

Yao and adds Walnut’s custom protocol for string substitution

for the common types of applets on IFTTT (

4). W-I builds

on W-C and adds the use of digital signatures and TEEs for

integrity guarantees (

5). Walnut (W) builds on W-I and adds

the use of token-chains for refreshing OAuth tokens (§6).

We perform a series of experiments to answer the eval-

uation questions. In each experiment, we deploy a system,

execute an applet (described below), and measure CPU time,

wall-clock time, network transfers, and storage space use. We

measure CPU time and network transfers using kernel account-

ing frameworks

/proc/pid/stat

and

/proc/net/dev

, re-

spectively. We measure wall-clock time by instrumenting

code with Python’s

time.time()

, and storage space use by

Walnut’s code will be made available on GitHub after its publication.

CPU time CPU time CPU time

for 10B for 100B for 1000B

secret sharing-related

XOR share 5.7 µs 21.0 µs 178.0 µs

XOR reconstruct 5.2 µs 32.0 µs 306.0 µs

encryption-related

ECIES encrypt 473.0 µs 491.0 µs 498.0 µs

ECIES decrypt 486.0 µs 491.0 µs 514.0 µs

signature-related

ECDSA sign 685.0 µs 692.0 µs 695.0 µs

ECDSA verify 550.0 µs 555.0 µs 559.0 µs

CPU time network transfers

Yao-related

φ = integer comparison 90.0 µs 6.2 KB

φ = string substitution 294.3 ms 862.1 KB

Figure 8: CPU times and network transfers for cryptographic

operations in Walnut and the baselines. The key-sizes of ellip-

tic curve-based ECIES and ECDSA are 256 bits. The elliptic

curve used is secp256k1. The overheads of Yao depend on

the function being computed inside Yao; integer compari-

son compares two 32-bit integers, and the string substitution

function replaces the braces in the template string “This is a

substitution {}” with another string of length 100 bytes.

reading statistics returned by MongoDB’s collStats.

We execute the “Get a daily 6:00 AM email with the

weather report” applet from Weather Underground [

]. We

choose this applet because it is both popular (installed over

30K times) and representative of the common IFTTT applet.

We run this applet with three types of ﬁlterCode. The “passing

around” ﬁlterCode sets the body of the email to the value of

the key-value pair with key “new weather type” in trigOut.

The “string sub” ﬁlterCode sets the body of the email by

substituting the placeholder in the template string “This is

an example of a substituted string. The new type of weather

{{

new weather type

}}

” with the key-value pair with key

“new weather type” in trigOut. The “custom code” ﬁlterCode

sets the email body to a variant of the string above depending

on the type of weather (“sunny” versus “rainy”). For Walnut

and its variants, we pad the template strings and the values

in trigOut as described in Section 4. We conﬁgure Walnut to

pad each block in a string to a power-of-two length.

Our testbed (Figure 7) is a set of VMs on Google Cloud,

Microsoft Azure, and IBM Cloud. We run the trigger and

action services on Google Cloud, and Walnut’s two servers on

Azure and IBM. Within Azure and IBM, we use both general-

purpose and TEE machines. Cloud providers currently offer

only Intel SGX-based TEEs [

]; we use three such machines

as the three TEEs for W-I and Walnut. However, the TEE

availability on cloud providers is improving [

], and in a

real deployment, Walnut would use three different TEEs.

Microbenchmarks.

Figure 8 shows CPU and network costs

for common cryptographic operations in Walnut and the base-

lines on machines of type B1.1x2 (Figure 7). Walnut uses el-

liptic curve-based encryption and signature schemes (ECIES

Pass Arnd String Sub Custom code

CPU time (milliseconds)

Applet filtercode

NoSec

17.6

W-Yao

221.8

310.8

312.0

W-C

50.1

50.2

312.0

W-I

61.5

61.6

949.5

62.0

62.9

950.3

Pass Arnd String Sub Custom code

Network transfers (KBs)

Applet filtercode

NoSec

3.6

3.7

W-Yao

1325.1

2290.2

2321.6

W-C

13.5

13.7

2321.6

W-I

14.9

15.2

6966.1

15.4

15.7

6966.6

Figure 9: Platform-side CPU time and network transfers for Walnut and the baseline systems for different ﬁlterCodes.

0.01

0.1

100

Pass Arnd String Sub Custom code

Latency (seconds)

Applet filtercode

NoSec

0.13

W-Yao

3.9

4.09

4.18

W-C

0.15

4.18

W-I

0.17

4.25

0.17

4.26

Figure 10: Platform-side trigger-action latency.

and ECDSA, respectively). We will use these microbench-

marks to explain the numbers in the next subsections.

8.1 Platform-side overheads

CPU overhead.

Figure 9 (a) shows platform-side CPU over-

head while varying the system and the ﬁlterCode in our work-

load applet. At a high level, the CPU overhead increases as

the complexity of ﬁlterCode increases. For instance, Walnut’s

CPU time is 62.0 ms for pass arnd, 62.9 ms for string sub, and

950.3 ms for custom ﬁlterCode.

For all three ﬁlterCode types, NoSec consumes the least

CPU, while W-Yao and Walnut consume the most. For in-

stance, for the string sub ﬁlterCode, W-C, W-I, Walnut, and

W-Yao consume 2.9

, 3.5

, 3.6

, and 17.7

the CPU time

of NoSec. This trend is expected as NoSec operates over

plaintext data and does not provide integrity properties, while

W-C adds secret-sharing, encryption, and tailored string sub-

stitution over shares of strings (Figure 3 in

4), W-I further

adds signature veriﬁcation and generation inside TEEs (Fig-

ure 5 in

5), and Walnut adds token-chain to W-I (

6). W-Yao

consumes high CPU as it performs string substitution over an

encrypted Boolean circuit (§4).

Meanwhile, the CPU times connect back to microbench-

marks (Figure 8). For instance, Walnut adds 12.7 ms of CPU

time relative to W-C for the string sub ﬁlterCode. This is

primarily due to three pairs of signature generation and six

pairs of signature veriﬁcation using OpenSSL inside TEE

machines; each signature generation and veriﬁcation takes

≈0.7 ms and ≈0.55 ms, respectively.

Component NoSec applet Walnut Applet

title, description 27 bytes 27 bytes

ﬁlterCode 62 bytes 139 bytes

trigger 337 bytes 793 bytes

action 340 bytes 3506 bytes

total 766 bytes 4465 bytes

Figure 11: Comparison of storage space consumed by a

NoSec applet and a Walnut applet .

Network overhead.

Figure 9 (b) shows platform-side net-

work overhead for the various systems and ﬁlterCodes. The

network trends resemble those for CPU. The costs increase

with ﬁlterCode complexity, and for each type of ﬁlterCode,

W-C, W-I, Walnut, and W-Yao incur successively increasing

cost over NoSec, except for the custom code ﬁlterCode where

W-C behaves like W-Yao.

Walnut incurs overhead over NoSec because it transfers

serialized ciphertexts, secret-shares, signatures, and token-

chains during the trigger-polling, action-generation, and

action-execution steps of Walnut’s protocol (

4–

6). As an

example, consider the trigger-polling message from Walnut’s

ﬁrst server to the trigger service. In NoSec, the header of the

message is 219 bytes, while it is 383 bytes in Walnut. The

header increases by 164 bytes because the 64 byte OAuth

token in NoSec is ECIES-encrypted to a 161-byte ciphertext,

and then serialized to a ﬁnal size of 228 bytes (step 4 in Fig-

ure 5). Similarly, the body of the polling message is 150 bytes

in NoSec and 826 bytes in Walnut, due to the addition of sev-

eral ﬁelds including 231 bytes of encrypted trigInp, 126 bytes

of a signature over trigInp, and 403 bytes of a token-chain.

Latency overhead.

Figure 10 shows the time it takes for the

various systems to execute an applet. Our wall-clock timing

begins when the platform initiates the trigger-polling request

to the trigger service, and ends when the action services re-

ceive the action details. Walnut’s latency is 1.3

, 1.3

, and

32.7

of NoSec’s latency for the three types of ﬁlterCode.

The latency increase for the custom ﬁlterCode is high because

it calls the expensive Yao’s protocol.

Storage overhead.

Figure 11 shows Walnut’s and NoSec’s

storage space use for the applet with the string sub ﬁlterCode.

Overall, Walnut’s applet takes 5.8

the storage space required

by the NoSec applet. This extra storage is due to the additional

Pass Arnd String Sub Custom code

CPU time (milliseconds)

Applet filtercode

NoSec

3.5

3.6

W-Yao

7.6

W-C

7.6

7.7

7.6

W-I

9.9

10.0

11.2

11.3

Pass Arnd String Sub Custom code

Network transfers (KBs)

Applet filtercode

NoSec

2.1

2.2

W-Yao

4.7

W-C

4.6

4.7

W-I

5.0

5.3

Figure 12: Trigger-service CPU time and network overhead for Walnut and the baseline systems for different ﬁlterCodes.

Pass Arnd String Sub Custom code

CPU time (milliseconds)

Applet filtercode

NoSec

5.3

W-Yao

7.0

7.2

7.3

W-C

7.0

7.2

7.3

W-I

11.3

11.4

11.5

11.6

Pass Arnd String Sub Custom code

Network transfers (KBs)

Applet filtercode

NoSec

9.2

9.3

W-Yao

9.8

10.0

10.1

W-C

9.8

10.0

10.1

W-I

10.9

11.1

11.3

11.0

11.2

11.3

Figure 13: Action-service CPU time and network overhead for Walnut and the baseline systems for different ﬁlterCodes.

components in Walnut’s applet, such as secret-shares of setup-

time values of actInp, and the overhead of encrypting, signing,

and serializing the components.

8.2 Service-side overheads

Trigger service overheads.

Figure 12 (a) shows CPU time

for the various systems and the three types of ﬁlterCodes in

our workload applet. The CPU times have two notable aspects.

First, Walnut’s CPU time is 3.2

that of NoSec. The overhead

comes from conﬁdentiality techniques (decryption of trigInp

ciphertexts and creation of trigOut secret shares) and integrity

design (veriﬁcation and generation of signatures). Second, the

overhead does not vary with ﬁlterCode. This trend is expected

as the trigger components of the three applets are the same.

Figure 12 (b) shows the trigger service’s network overhead.

This overhead is 2.5

that of NoSec. Also, as with the CPU

costs, the network trafﬁc is independent of the ﬁlterCode.

Action service overheads.

Figure 13 shows action service’s

CPU and network overhead for the various systems and ﬁl-

terCodes. Similar to the trigger service overheads, the CPU

costs are dependent on the system used. The CPU overhead of

Walnut relative to NoSec is due to the decryption and merging

of actInp shares, and signature veriﬁcation for the “proofs”

from TEEs and the token-chain (§5, §6).

The network overhead also increases with the security pro-

vided by the system, and with the ﬁlterCode. The variation

across ﬁlterCodes is due to the fact that different ﬁlterCodes

result in actInp of different lengths. Finally, we notice that

for NoSec the action service-side network transfers (9.3 KB)

are larger than the platform-side network transfers (3.7 KB;

Figure 9 (b)). This is because the action service also commu-

nicates with Gmail to authenticate and send emails.

8.3 Dollar Cost

Walnut’s added overheads (

8.1) increase dollar cost for the

platform provider for running an applet. In this section, we

estimate these costs by converting Walnut’s raw resource

overheads into a dollar amount using a pricing model derived

from machine and data transfer prices of Microsoft Azure

(Appendix A). This model charges CPU at $0.198/hour and

network transfers at $0.087/GB.

Figure 14 shows the resulting dollar costs for the three

types of ﬁlterCodes (passing around, string substitution, and

custom code). For the common ﬁlterCodes (passing around

and string substitution), Walnut increases cost by 3.7

and

3.74

. However, for the custom code ﬁlterCode, Walnut in-

creases cost by 510.4×.

8.4 Compatibility

One of Walnut’s goals is to run any IFTTT applet. To study

whether Walnut can meet this requirement, we implemented,

using Walnut, (i) 15 randomly selected IFTTT applets from

the 50 most popular applets in the dataset of Mi et al. [

and (ii) 15 IFTTT applets whose applet IDs were randomly

generated (Appendix B). We found that IFTTT applets can

be implemented on Walnut in a short time—it took us 96

developer-hours to implement and test these applets.

CPU time

Network

transfers

$-cost relative

to NoSec

passing around

NoSec 17.6 ms 3.6 KB 1×

Walnut 62 ms 15.4 KB 3.7×

string substitution

NoSec 17.6 ms 3.7 KB 1×

Walnut 62.9 ms 15.7 KB 3.74×

custom ﬁlterCode

NoSec 17.6 ms 3.7 KB 1×

Walnut 950.3 ms 6966.6 KB 510.4×

Figure 14: Dollars spent to run an applet on NoSec, Walnut.

9 Related work

Conﬁdentiality and integrity risks in IoT middleware.

et al. [

] study SmartThings, which is the Samsung platform

for managing Samsung smart devices, and report the move-

ment of sensitive information from SmartThings to IFTTT.

Fernandes et al. [

] also report security issues with Smart-

Things, in particular, over-privilege of access tokens. For

example, a SmartThings application may get a capability for

locking and unlocking a Samsung device even if it needs

to only call lock. Like SmartThings, IFTTT exhibits over-

privilege: 75% of IFTTT services issue broad-scoped OAuth

tokens [25, 26], as discussed earlier (§2).

Walnut is inspired by these works. It focuses on limiting the

exposure of sensitive data at the platform and and ensuring

that the platform does not misuse tokens (that is, always

performs the precise action intended by the user).

Reducing risks in trigger-action platforms.

Almond [

]

is a virtual assistant that connects trigger and action services.

Unlike IFTTT, it allows the users to program applets using

natural language (rather than mouse clicks that build automa-

tion programs). Almond preserves conﬁdentiality but makes

strong trust assumptions: it runs inside a single trusted device.

Xu et al. [

] use a ﬁlter-and-fuzz approach to provide

conﬁdentiality. The ﬁlter part enables the trigger service to

eliminate parameters that are either not needed by an applet

or do not result in the ﬁring of an action. The fuzz part adds

dummy trigger outputs to drown real outputs that cannot be

ﬁltered. Filter-and-fuzz approach has a limited applicability

as it assumes that the trigger service has knowledge of the

actions. Indeed, Xu et al. apply their approach to Samsung’s

SmartThings where trigger and action services are in the

same domain. Furthermore, the approach adds high CPU and

network overhead to transfer and process dummy events.

DTAP [

] eliminates over-privilege of OAuth tokens

by using applet-speciﬁc access tokens. In DTAP, a trigger

service signs trigOut, the platform processes the output in

plaintext to generate actInp, and the action service veriﬁes

both the signature over trigOut and the correctness of actInp.

DTAP does not hide sensitive data from the platform. Besides,

it sends the entire trigOut structure to the action service to

verify signature and action-correctness.

Functionality

Conf. Data Min. Integrity

Efﬁciency

DTAP [25, 26]

Filter-Fuzz [78]

Walnut (§3–§6)

Figure 15: Comparison of Walnut to prior work for trigger-

action platforms. An empty circle ( ) denotes that the system

does not address the particular concern, while a full circle ( )

denotes that the system performs close to the ideal. The other

circles fall in between in an increasing order of superiority.

Walnut also targets security improvements for a trigger-

action platform. However, relative to prior work, it provides

both conﬁdentiality and integrity guarantees (Figure 15). Fur-

thermore, in line with the principle of least privilege [

]

(also called data minimization in modern privacy regula-

tion [

]), Walnut ensures that the services learn only the

information that is input to the trigger and action APIs.

Reducing risk in other types of IoT middleware.

Bolt [

]

targets applications for smart homes (e.g., ﬁnding a lost pet in

a neighborhood). It stores data on an untrusted cloud provider

but runs applications on trusted in-home devices.

BeeKeeper [

] targets a streaming scenario in which an

IoT device streams data to a blockchain-based “leader” who

runs a query on it. BeeKeeper uses secret-sharing and se-

cure multi-party computation [

] to provide conﬁdential-

ity, and threshold-cryptography to provide integrity. How-

ever, BeeKeeper does not target trigger-action scenarios; in-

stead, it computes quadratic polynomials (mean, variance,

and standard-deviation). Jayaraman et al. [

] target the same

scenario as BeeKeeper. However, in contrast to BeeKeeper,

they use Paillier encryption and do not provide integrity.

General-purpose crypto primitives for security.

Secure

computation [

] and homomorphic encryption [

]

are vibrant areas of research [

]). These general-purpose primitives support arbitrary com-

putation but are expensive. Walnut uses Yao’s two-party pro-

tocol but only for a small fraction of applets (§4).

Zero-knowledge proof systems have also seen tremendous

development [

]. However, the party

generating the proof incurs a large CPU time.

Walnut instead uses a mix of digital signatures and TEEs

for proving execution integrity at low overhead (§5).

10 Conclusion

Trigger-action platforms like IFTTT have gained traction due

to their convenience and connectivity. However, these cloud-

hosted platforms present conﬁdentiality and integrity risks.

This paper asked the question, can we build a fortiﬁed alter-

native to IFTTT at a low resource cost, and found the results

to be encouraging. In particular, one can gain signiﬁcantly on

security while restricting resource (CPU, network) overhead

to 4.3

for all but a small fraction of programs. Walnut’s

enabler is a new secure computation protocol that is tailored

for common computation on IFTTT and that distributes trust

over heterogenous trusted-hardware machines from different

vendors. By demonstrating these promising results, Walnut

provides a beneﬁt to both users and platform providers—they

can enjoy trigger-action automation with signiﬁcant improve-

ment in data conﬁdentiality and integrity.

A Pricing model

To get the dollar-cost of running an applet, we take the CPU

and network cost from our benchmarks and add them linearly

(

8.3). That is, if C is the hourly CPU cost and D is the price

for transferring one GB of data over the network, the dollar

cost to run each applet is of the form

+ β

D, where

the CPU time required to run the applet and

is the amount

of data transferred to or from the Walnut platform during

execution. Our goal in this appendix is to estimate the values

of C and D.

The network cost is taken from the “outbound data transfer”

costs for Microsoft Azure which gives D

0.087 (dollars per

GB) [

]. Meanwhile, estimating CPU cost is not straightfor-

ward. Machine prices on cloud providers are set using several

factors including maintenance and running expenses, market

demand, and peripheral costs such as DDoS protection and

load-balancing. Therefore, we make a simplifying assump-

tion that the machine cost on cloud providers is dominated

by the cost of CPU. We take the hourly cost of a DC4s v2

SGX machine on Microsoft Azure [

] that we use in our

experiments and divide by 4, which is the number of cores on

this machine. This method gives C = 0.198 (dollars/hour).

B Compatibility study applets

•

The following 15 applets were randomly selected from the

set of the 50 most popular applets from the dataset of Mi

et al. [59]:

“Get a daily 6:00 AM email with the weather report”

(https://ifttt.com/applets/Zv56ZXwR)

“Update your Android wallpaper with NASA’s im-

age of the day” (

https://ifttt

com/applets/

yNvHX9VQ)

“Sync all your new iOS Contacts to a Google Spread-

sheet” (https://ifttt.com/applets/dycqQ5A6)

“Automatically change your Twitter proﬁle pic

when you update your Facebook photo” (

https:

//ifttt.com/applets/qFZqXrvs)

“Automatically back up your new iOS photos

to Google Drive” (

https://ifttt

com/applets/

90254p)

“Send a text message to someone with your An-

droid and Google Home” (

https://ifttt

com/

applets/fNdGJfwy)

“Sync your Amazon Alexa to-dos with your reminder”

(https://ifttt.com/applets/ieCE52WK)

“Track your work hours in Google Calendar” (

https:

//ifttt.com/applets/sFk2WC4r)

“Quickly create events in Google Calendar” (

https:

//ifttt.com/applets/192007p)

10.

“Press a button to track work hours in Google Drive”

(https://ifttt.com/applets/227069p)

11.

“Back up new iOS photos you take to Dropbox”

(https://ifttt.com/applets/103376p)

12.

“Backup your new Instagram photos to Dropbox”

(https://ifttt.com/applets/25679p)

13.

“Post your Instagram photos to Tumblr” (

https://

ifttt.com/applets/131p)

14.

“Post your Instagram photos as native Twitter pho-

tos when #twitter is in the caption” (

https://

ifttt.com/applets/68915p)

15.

“Tell Alexa to email you your shopping list” (

https:

//ifttt.com/applets/284243p)

•

The following 15 applets were randomly selected from a

set of 78 randomly generated applet IDs:

“bloggin’ via Instagram: STEP 2 Flickr -

Tumblr”

(https://ifttt.com/applets/7p)

“End Harmony Activity using MESH” (

https://

ifttt.com/applets/6163)

“Receive a notiﬁcation when occupancy is detected”

(https://ifttt.com/applets/3820)

“Turn on Wemo Smart Plug using MESH” (

https:

//ifttt.com/applets/6190)

“bloggin’ via Instagram: STEP 1 Instagram -

Flickr”

(https://ifttt.com/applets/6p)

“Tweet your newest uploaded Flickr pictures.”

(https://ifttt.com/applets/29p)

“Carry important ﬁle everywhere!” (

https://

ifttt.com/applets/86p)

“Record each time you connect to your TP-Link

network in a Google Spreadsheet” (

https://

ifttt.com/applets/6997)

“Test ifttt 1” (

https://ifttt

com/applets/

09018)

10.

“Switch on a socket with Amazon Alexa” (

https:

//ifttt.com/applets/6569)

11.

“Flickr favorites to Evernote” (

https://ifttt

com/

applets/33p)

12.

“Get an email when motion is detected at your front

door” (https://ifttt.com/applets/3726)

13.

“Sing a love song to IFTTT Voicemail, send it straight

to my sweetheart” (

https://ifttt

com/applets/

11p)

14.

“Daily Forecast” (

https://ifttt

com/applets/

2950p)

15.

“Post your new Instagram videos with a speciﬁc

hashtag to a Telegram chat” (

https://ifttt

com/

applets/4657)

C Security proofs

We ﬁrst introduce deﬁnitions for the basic cryptographic prim-

itives such as secret-sharing, encryption, and signatures that

Walnut’s protocol builds on. We then present the proofs for

the passive and active security settings (§3.2).

C.1 Basic cryptographic primitives

Secret-sharing.

Walnut uses a 2-out-of-2 XOR secret-sharing

scheme, where both the shares are required to reconstruct the

secret. This scheme consists of two algorithms.

• Share(

∈ {

0, 1

}

) → (

k, k

)

takes as input a

-bit string

and generate two secret-shares of the string: k and k

. In-

ternally, the procedure ﬁrst samples k

∈

{

0, 1

}

and then

computes k

← k ⊕ s.

• Reconstruct(k, k

) outputs s ← k ⊕ k

Correctness of the scheme requires the shares produced to be

reconstructable. Security requires that an adversary cannot

distinguish between the shares of two different input strings

of the same length.

Encryption scheme.

Walnut relies on an encryption scheme

that is IND-CPA and IND-CCA2 secure. It consists of two

algorithms.

• Enc(

pk, m

) →

takes in the public key, and the plaintext

message and outputs a ciphertext.

• Dec(

sk, C

) →

m takes in the secret key and a ciphertext

and outputs the plaintext message.

Correctness requires that ciphertexts produced from the

scheme can be decrypted to obtain back the original plain-

text. Security requires that the ciphertexts produced for two

different plaintext messages are indistinguishable. Walnut’s

implementation uses the elliptic-curve based ECIES encryp-

tion scheme (§8).

Signature scheme.

Walnut relies on a standard signature

scheme which consists of two algorithms.

• Sign(

sk, m

) → σ

takes in a secret key and a message and

outputs a signature.

• Verify(

pk, m,

) → {True

⊥}

takes in the public key, the

message, and the signature, and returns either True or

⊥

indicate whether the signature on the message is valid or

not.

Correctness requires that a signature produced from the

scheme can be successfully veriﬁed by the veriﬁcation algo-

rithm. Security requires the unforgeability of a valid signature

by an adversary, that is, an adversary cannot (without the

secret key) produce a signature that outputs True from the

veriﬁcation algorithm.

We now move to the proofs for Walnut’s protocol.

C.2 Proof for passive security

Our goal here is to prove that the protocol described in Sec-

tion 4 (Figure 3) meets the passive security deﬁnition in Sec-

tion 3.2.

We prove the security of the protocol using the simulation

proof technique. Essentially, in this technique, there is an

ideal world adversary called the simulator which resides in

the ideal world (which is secure by deﬁnition). The real world

adversary interacts with the simulator, and the simulator simu-

lates the messages output by the honest parties in the protocol.

The simulator has access to the signing keys of the honest

parties. The protocol is said to be secure if such a simulator

exists and the adversary cannot distinguish between the real

execution of the protocol and the simulated execution.

Suppose there exists a PPT adversary

that compromises

the general purpose machine M

for some b

∈ {

0, 1

}

. The

honest parties in the passive setting are trigger service TS,

action service AS, and the general-purpose machine M

1−b

We then construct a PPT simulator Sim as follows:

1. Sim

chooses a uniform random tape for the corrupted

party M

Sim

simulates the honest parties TS, AS, M

1−b

2. In Setup phase:

(a) Sim

sends encryptions of zeros as access tokens

and trigInp. That is, C

at-TS

Sim

← Enc(

, 0

|at-TS|

)

at-AS

Sim

← Enc(

, 0

|at-AS|

)

, and C

trigInp

Sim

←

Enc(pk

, 0

|trigInp|

(b) Sim

replaces each sh

)

not of the form

{{

key-

name}} in each sh

(actInp)

[k] with Share(0

)[b].

3. In trigger-polling phase: Sim

replaces each sh

)

each sh

(trigOut)

[k] with Share(0

)[b].

4. In action-generation phase:

depending on the ﬁlter-

Code,

Sim

runs the simulator of Yao’s protocol or the

custom string substitution protocol (described shortly

below). In either case, the simulator is programmed to

output shares of the action input parameter sh

(actInp)

cho-

sen uniformly at random.

5. In action-execution phase: Sim does nothing.

We now show that the distribution of the messages in the real

protocol and the outputs of the simulator are computationally

indistinguishable using the standard hybrid technique. This

technique refers to the strategy of proving that two tuples of

distributions

(

. . .

, D

)

and

(

. . .

, D

)

are computation-

ally indistinguishable, if all the D

s (respectively, D

s) are

independently generated, and D

is computationally indistin-

guishable from D

. The strategy is to consider a sequence of

hybrid distributions

(

. . .

, D

i−1

, D

. . .

, D

)

and proving

every consecutive tuples of distributions are computationally

indistinguishable.

Hyb

: This corresponds to the real world distribution

where trigger service TS, action service AS and machine

1−b

execute the protocol as described in Section 4.

Hyb

: In this hybrid, we change the ciphertexts of tokens

and trigInp sent to TS, and ciphertext of tokens sent

to AS. More speciﬁcally, we replace the encryption of

tokens and trigInp with a bit strings chosen uniformly at

random. Hyb

≈

Hyb

due to the semantic security of

the encryption scheme.

Hyb

: In this hybrid, we change the shares of actInp and

trigOut. More speciﬁcally, each sh

)

not of the form

{{

key-name

}}

in each sh

(actInp)

[

]

and sh

(trigOut)

[

]

replaced with bit strings chosen uniformly at random.

Hyb

≈

Hyb

due to the security of the secret sharing

scheme.

4. Hyb

: In this hybrid, the simulators for either Yao’s pro-

tocol or custom string substitution protocol is invoked

which outputs honest shares of action input parameter

(actInp)

. Hyb

≈

Hyb

due to the simulation security of

Yao’s and custom string substitution protocols (we prove

the latter below).

Hyb

: In this hybrid, we replace sh

(actInp)

output from ei-

ther Yao’s protocol or custom string substitution protocol

with bit strings chosen uniformly at random. Hyb

≈

Hyb

due to the security of secret-sharing.

Hyb

: This corresponds to the output distribution of

Sim

Hybrids Hyb

and Hyb

are identically distributed.

Proof of security for custom string substitution.

Deﬁnition C.1.

The custom string substitution protocol de-

scribed in Figure 4 is said to be

L-

secure if for any honest-

but-curious (passive) probabilistic polynomial time (PPT)

adversary

corrupting M

for some b

∈ {

0, 1

}

, for a leak-

age function

, for every large enough security parameter

there exists a PPT simulator

Sim

with access to the leakage

function, such that the output distribution of the simulator is

computationally indistinguishable from the adversary’s view

in the real protocol.

The simulator for string sub is constructed as follows:

1. Sim

replaces each sh

)

in each sh

(trigOut)

[

]

with

Share(0

)[b].

Similarly,

Sim

replaces each sh

)

not of the form

{{

key-

name}} in each sh

(actInp)

[k] with Share(0

)[b].

3. Sim

replaces each sh

)

in each sh

(actInp)

[

]

output from

GenerateAI with Share(0

)[b] and outputs sh

(actInp)

We now show that the distribution of the messages in the real

protocol and the outputs of the simulator are computationally

indistinguishable using the hybrid technique.

Hyb

: This hybrid corresponds to the real world distribu-

tion of the execution of string sub function by machine

. That is, {string sub(sh

(trigOut)

, sh

(actInp)

)}.

Hyb

: In this hybrid, we change the share of trigOut to

secret shares of zero. More speciﬁcally, each sh

)

each sh

(trigOut)

[k] is replaced with Share(0

)[b].

Hyb

: In this hybrid, we change the share of actInp input

parameter to secret shares of zero. More speciﬁcally, each

)

not of the form

{{

key-name

}}

in each sh

(actInp)

[

]

is replaced with Share(0

)[b]. Hyb

≈

Hyb

≈

Hyb

due to the semantic security of secret sharing scheme.

Hyb

: This corresponds to the output distribution of

Sim

Hybrids Hyb

and Hyb

are identically distributed.

C.3 Proof for active security

Our goal here is to prove that the protocol described in Sec-

tion 5 (Figure 5) and Section 6 meets the active security

deﬁnition in Section 3.2. We ﬁrst formalize the notion of

token-chains (§6) and then present the proof.

Deﬁnition C.2

(Token-chains)

Let at

and rt

de-

note the access and refresh token for trigger service TS in

epoch

, and let at

and rt

denote the access and

refresh token for action service AS for epoch

. We de-

ﬁne chain

equal to

Enc(

, at

)

as the token

chain for the trigger service TS for epoch

, and

←

Sign(

, chain

)

as the signature over the chain. Similarly,

we deﬁne chain

and

. Walnut’s protocol for active secu-

rity adds chain

, σ

, chain

, and σ

to App

Suppose there exists a PPT adversary

that compromises

the general purpose machine M

for b

∈ {

0, 1

}

and TEE ma-

chines T

(i)

and T

(j)

for some i, j

∈ {

0, 1, 2

}

. Then the honest

parties in the active setting are trigger service TS, action ser-

vice AS, TEEs T

(k)

, T

(i)

1−b

, T

(j)

1−b

, T

(k)

1−b

, and the general purpose

machine M

1−b

. Let k be such that k

i and k

j. We then

construct a PPT simulator

Sim

simulating the behavior of the

honest parties as follows.

1. In setup phase:

(a) Sim

sends encryptions of zeros as access tokens

and trigInp, that is, C

at-TS

Sim

← Enc(

, 0

|at-TS|

)

at-AS

Sim

← Enc(

, 0

|at-AS|

)

, and C

trigInp

Sim

←

Enc(pk

, 0

|trigInp|

(b) Sim

replaces each sh

)

not of the form

{{

key-

name}} in each sh

(actInp)

[key] with Share(0

)[b].

sends encryptions of zeros as the token

chains, that is, chain

Sim

← Enc(

, 0

|chain

)

chain

Sim

← Enc(pk

, 0

|chain

(d) Sim

generates simulated signatures

for

the uniform random ciphertexts chain

Sim

, chain

Sim

and simulated T, respectively.

2. In trigger-polling phase:

(a) Sim

asks

for its inputs to the trigger service TS:

, chain

Sim

additionally aborts the pro-

tocol if signature veriﬁcation of σ

and σ

fails.

(b) Sim

simulates trigger output tout

by generating

simulated shares of sh

(trigOut)

: replacing each sh

)

in sh

(trigOut)

[

key

]

with Share(0

)[b] and generating

simulated signature σ

tout

on tout

and σ

tout

to A.

3. In action-generation phase:

(a) Sim

asks

for its input tout

to the non-

compromised TEE T

(k)

Sim

runs the checks de-

scribed in step 7a of Figure 5 and aborts the protocol

if veriﬁcation fails.

(b) Sim

simulates the generated action input parame-

ter shares sh

(actInp

)

of TEE T

(k)

by sampling each

(actInp

)

[

key

]

for

(

key, v

)

in sh

(actInp

)

uniformly at

random.

Sim

also generates simulated

proof-

(k)

the simulated ain

(k)

then depending on the ﬁlterCode, invokes the

simulator for maliciously secure Yao’s protocol

(this is Yao’s protocol secure against honest-but-

curious adversaries but with the underlying oblivi-

ous transfer sub-protocol replaced by a variant of

oblivious transfer secure against malicious adver-

saries [

]) and generates simulated action input

shares sh

(actInp

)

, sh

(actInp

)

, and proofs

proof-

(i)

and

proof-T

(j)

as described in the above step.

(d) Sim

sends ain

(i)

, ain

(j)

, ain

(k)

proof-

(i)

proof-

(j)

and proof-T

(k)

to M

4. In action-execution phase:

(a) Sim

asks

for its inputs to the action service AS:

ainp

proof-

(i)

proof-

(j)

proof-

(k)

, chain

and σ

(b) Sim

runs step 9 of Figure 5 and checks RID as

mentioned in step 10 of Figure 5.

5. In token-refresh phase:

(a) Sim

asks

for its inputs to the TS: chain

and

TS.

Sim

checks the signature

on chain

and

aborts the protocol if the veriﬁcation fails.

(b) Sim

generates simulated chain chain

`+1

←

Enc(

, 0

|chain

)

, and signature

`+1

←

Sign(

, chain

`+1

)

Sim

sends chain

`+1

and

`+1

to A.

Sim

behaves symmetrically if the token-refresh request

is for AS.

We now show that the distribution of the messages in the real

protocol and the outputs of the simulator are computationally

indistinguishable using the hybrid technique.

Hyb

: This hybrid corresponds to the real world distribu-

tion where trigger service TS, action service AS, machine

1−b

, and TEE machines T

(k)

and T

(k)

execute the pro-

tocol described in Figure 5.

Hyb

: In this hybrid, we change the ciphertexts of tokens

and trigInp sent to TS, and ciphertext of tokens sent

to AS. More speciﬁcally, we replace the encryption of

tokens and trigInp with bit strings chosen uniformly at

random. The signatures

and

are also updated

accordingly. Hyb

≈

Hyb

due to the semantic security

of the encryption scheme.

Hyb

: In this hybrid, the shares of trigOut in tout

ob-

tained as the output of trigger-polling phase sh

(trigOut)

replaced with a bit string sampled uniformly at random.

The signature

tout

is updated according to the simu-

lated value of tout

. Hyb

≈

Hyb

due to the security of

secret-sharing.

Hyb

: This hybrid is same as Hyb

but

Sim

veriﬁes

in the trigger-polling phase and aborts if

the veriﬁcation fails. Hyb

is identically distributed to

Hyb

: In this hybrid, the action generation output of T

(k)

(actInp

)

is replaced with a bit string sampled uniformly

at random. The signature

proof-

(k)

is updated according

to the simulated value of ain

(k)

. Hyb

≈

Hyb

due to

the security of the secret-sharing scheme.

Hyb

: In this hybrid, the simulator of Yao’s protocol

that outputs honest shares sh

(actInp

)

, sh

(actInp

)

is invoked.

Hyb

≈

Hyb

due to the simulation security of Yao’s

protocol.

Hyb

: In this hybrid, the shares sh

(actInp

)

, sh

(actInp

)

output

from the simulator of Yao is replaced with bit strings

chosen uniformly at random. The signatures

proof-

(i)

and

proof-

(j)

are updated according to the simulated

value of ain

(i)

, ain

(j)

. Hyb

≈

Hyb

due to the security

of the secret-sharing scheme.

Hyb

: In this hybrid,

Sim

additionally runs signature

checks mentioned in step 7a of Figure 5 and aborts if

veriﬁcation fails. Hyb

is identically distributed to Hyb

9. Hyb

: In this hybrid, Sim additionally runs checks men-

tioned in step 9 of Figure 5 and aborts if veriﬁcation fails.

Hyb

is identically distributed to Hyb

10.

Hyb

: This hybrid corresponds to the output distribu-

tion of

Sim

in the ideal execution. Hyb

and Hyb

are

identically distributed.

Acknowledgments

We thank Prabhanjan Ananth, Gareth George, Muqsit Nawaz,

Srinath Setty, Yang Wang, and Rich Wolski for feedback and

comments that helped improve this draft.

References

[1] California consumer privacy act (CCPA).

https://oag.ca.gov/privacy/ccpa.

[2] The EU general data protection regulation (GDPR).

https://eugdpr.org/.

[3] SGX-LKL library OS for running Linux applications

inside of Intel SGX enclaves.

https://github.com/lsds/sgx-lkl, 2019.

[4] Amazon. AWS Nitro Enclaves: Create additional

isolation to further protect highly sensitive data within

EC2 instances. https:

//aws.amazon.com/ec2/nitro/nitro-enclaves/.

[5] ARM. ARM security technology: Building a secure

system using TrustZone technology. White paper, 2008.

[6] M. Backes, M. Barbosa, D. Fiore, and R. M. Reischuk.

ADSNARK: Nearly practical and privacy-preserving

proofs on authenticated data. In IEEE Symposium on

Security and Privacy (S&P), 2015.

[7] R. Barry and D. Volz. Ghosts in the Clouds: Inside

China’s Major Corporate Hack. The Wall Street

Journal, Dec. 2019. https://www.wsj.com/

articles/ghosts-in-the-clouds-inside-

chinas-major-corporate-hack-11577729061.

[8] B. Baruah and S. Dhal. A two-factor authentication

scheme against FDM attack in IFTTT based Smart

Home System. Computers & Security, 77:21–35, 2018.

[9] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza.

Succinct non-interactive zero knowledge for a von

Neumann architecture. In USENIX Security

Symposium, 2014.

[10] B. Bond, C. Hawblitzel, M. Kapritsos, K. R. M. Leino,

J. R. Lorch, B. Parno, A. Rane, S. Setty, and

L. Thompson. Vale: Verifying high-performance

cryptographic assembly code. In USENIX Security

Symposium, 2017.

[11] B. Braun, A. J. Feldman, Z. Ren, S. Setty, A. J.

Blumberg, and M. Walﬁsh. Verifying computations

with state. In ACM Symposium on Operating Systems

Principles (SOSP), 2013.

[12]

G. Campagna, R. Ramesh, S. Xu, M. Fischer, and M. S.

Lam. Almond: The architecture of an open,

crowdsourced, privacy-preserving, programmable

virtual assistant. In International World Wide Web

Conference (WWW), 2017.

[13] N. Chandran, W. Chongchitmate, R. Ostrovsky, and

I. Visconti. Universally composable secure

computation with corrupted tokens. In Advances in

Cryptology—CRYPTO, 2019.

[14] H. Chen, D. Ziegler, T. Chajed, A. Chlipala, M. F.

Kaashoek, and N. Zeldovich. Using Crash Hoare logic

for certifying the FSCQ ﬁle system. In ACM

Symposium on Operating Systems Principles (SOSP),

2015.

[15]

A. Chiesa, E. Tromer, and M. Virza. Cluster computing

in zero knowledge. In Annual International Conference

on the Theory and Applications of Cryptographic

Techniques (EUROCRYPT), 2015.

[16]

I. Chillotti, N. Gama, M. Georgieva, and M. Izabachene.

Faster fully homomorphic encryption: Bootstrapping in

less than 0.1 seconds. In International Conference on

the Theory and Application of Cryptology and

Information Security (ASIACRYPT), 2016.

[17]

I. Chillotti, N. Gama, M. Georgieva, and M. Izabach

ene.

TFHE: Fast fully homomorphic encryption over the

torus. Journal of Cryptology, 33(1):34–91, 2020.

[18] O. M. Committee. OpenSSL.

https://www.openssl.org, 2018.

[19] G. Corﬁeld. Vengeful sacked IT bod destroyed

ex-employer’s AWS cloud accounts. Now he’ll spent

rest of 2019 in the clink. The Register, Mar. 2019.

https://www.theregister.co.uk/2019/03/20/

steffan_needham_aws_rampage_prison_

sentence_voova/.

[20] V. Costan and S. Devadas. Intel SGX explained.

Cryptology ePrint Archive, Report 86, 2016.

[21] C. Costello, C. Fournet, J. Howell, M. Kohlweiss,

B. Kreuter, M. Naehrig, B. Parno, and S. Zahur.

Geppetto: Versatile veriﬁable computation. In IEEE

Symposium on Security and Privacy (S&P), May 2015.

[22] P. J. Denning. Fault tolerant operating systems. ACM

Computing Surveys (CSUR), 8(4):359–389, 1976.

[23] C. Dixon, R. Mahajan, S. Agarwal, A. Brush, B. Lee,

S. Saroiu, and P. Bahl. An operating system for the

home. In USENIX Symposium on Networked Systems

Design and Implementation (NSDI), 2012.

[24] E. Fernandes, J. Jung, and A. Prakash. Security

analysis of emerging smart home applications. In IEEE

Symposium on Security and Privacy (S&P), 2016.

[25] E. Fernandes, J. Jung, and A. Prakash. Decentralized

action integrity for trigger-action IoT platforms. In

Network and Distributed System Security Symposium

(NDSS), 2018.

[26] E. Fernandes, A. Rahmati, J. Jung, and A. Prakash.

Decoupled-IFTTT: Constraining privilege in

trigger-action platforms for the internet of things. arXiv

preprint arXiv:1707.00405, 2017.

[27] A. Ferraiuolo, A. Baumann, C. Hawblitzel, and

B. Parno. Komodo: Using veriﬁcation to disentangle

secure-enclave hardware from software. In ACM

Symposium on Operating Systems Principles (SOSP),

2017.

[28]

P. Fonseca, K. Zhang, X. Wang, and A. Krishnamurthy.

An empirical study on the correctness of formally

veriﬁed distributed systems. In ACM European

Conference on Computer Systems (EuroSys), 2017.

[29] P. S. Foundation. Python Requests.

https://requests.readthedocs.io/en/master/,

2017.

[30] W. Gayde. Rogue system admin shuts down servers

and deletes core ﬁles on the day he is ﬁred, now faces

up to 10 years in prison. Techspot, Mar. 2017.

https://www.techspot.com/news/68753-rogue-

system-administrator-shuts-down-servers-

deletes-core.html.

[31] GE Appliances Cooking. If your smoke alarm detects

an emergency, then turn off your oven.

https://ifttt.com/applets/271914p-if-your-

smoke-alarm-detects-an-emergency-then-

turn-off-your-oven.

[32] D. Genkin, L. Pachmanov, I. Pipman, and E. Tromer.

Stealing keys from PCs using a radio: Cheap

electromagnetic attacks on windowed exponentiation.

In Conference on cryptographic hardware and

embedded systems (CHES), 2015.

[33] D. Genkin, I. Pipman, and E. Tromer. Get your hands

off my laptop: Physical side-channel key-extraction

attacks on PCs. Journal of Cryptographic Engineering,

5(2):95–112, 2015.

[34] C. Gentry. Fully homomorphic encryption using ideal

lattices. In ACM Symposium on Theory of Computing

(STOC), 2009.

[35] gkayy. Fitbit and iOS Health Sync.

https://ifttt.com/applets/By85n3Uv-fitbit-

and-ios-health-sync.

[36] O. Goldreich, S. Micali, and A. Wigderson. How to

play any mental game. In ACM Symposium on Theory

of Computing (STOC), 1987.

[37] T. Gupta, R. P. Singh, A. Phanishayee, J. Jung, and

R. Mahajan. Bolt: Data management for connected

homes. In USENIX Symposium on Networked Systems

Design and Implementation (NSDI), pages 243–256,

2014.

[38] D. Hardt. The OAuth 2.0 authorization framework.

RFC 6749, Internet Engineering Task Force, 2012.

[39] C. Hawblitzel, J. Howell, J. R. Lorch, A. Narayan,

B. Parno, D. Zhang, and B. Zill. Ironclad apps:

End-to-end security via automated full-system

veriﬁcation. In USENIX Symposium on Operating

Systems Design and Implementation (OSDI), 2014.

[40] A. Holzer, M. Franz, S. Katzenbeisser, and H. Veith.

Secure two-party computations in ANSI C. In ACM

Conference on Computer and Communications Security

(CCS), 2012.

[41] Y. Huang, D. Evans, J. Katz, and L. Malka. Faster

secure two-party computation using garbled circuits. In

USENIX Security Symposium, 2011.

[42] Y. Huang, J. Katz, and D. Evans. Quid-pro-quo-tocols:

Strengthening semi-honest protocols with dual

execution. In IEEE Symposium on Security and Privacy

(S&P), 2012.

[43] I. Inc. IFTTT: Every thing works better together.

https://ifttt.com/.

[44] Z. Inc. Zapier — The easiest way to automate your

work. https://zapier.com/home.

[45] ING Australia. Steps = savings. Connect your Fitbit

step goal to savings. https://ifttt.com/applets/

DvSLi9hE-steps-savings-connect-your-

fitbit-step-goal-to-savings.

[46] Instagram. Tweet your Instagrams as native photos on

Twitter. https://ifttt.com/applets/aVxGRrtD-

tweet-your-instagrams-as-native-photos-

on-twitter?term=twitter.

[47] Integromat. Integromat - The glue of the Internet.

https://www.integromat.com/en/.

[48] Intel. Intel Software Guard Extensions.

https://software.intel.com/en-us/sgx.

[49] P. P. Jayaraman, X. Yang, A. Yavari,

D. Georgakopoulos, and X. Yi. Privacy preserving

internet of things: From privacy techniques to a

blueprint architecture and efﬁcient implementation.

Future Generation Computer Systems, 76:540–549,

2017.

[50] D. Kaplan, J. Powell, and T. Woller. AMD memory

encryption. White paper, Apr. 2016.

[51]

M. Keller, E. Orsini, and P. Scholl. Actively secure OT

extension with optimal overhead. In Advances in

Cryptology—CRYPTO, 2015.

[52] P. Kocher, J. Jaffe, and B. Jun. Differential power

analysis. In Advances in Cryptology—CRYPTO, 1999.

[53] V. Kolesnikov, P. Mohassel, and M. Rosulek. FleXOR:

Flexible garbling for XOR gates that beats free-XOR.

In Advances in Cryptology—CRYPTO, 2014.

[54] V. Kolesnikov and T. Schneider. Improved garbled

circuit: Free XOR gates and applications. In

International Colloquium on Automata, Languages,

and Programming, 2008.

[55] Y. Lindell and B. Pinkas. A proof of security of Yao’s

protocol for two-party computation. Journal of

Cryptology, 22(2):161–188, 2009.

[56] G. LLC. Google Home - Smart Speaker & Home

Assistant - Google Store. https:

//store.google.com/us/product/google_home.

[57] D. Malkhi, N. Nisan, B. Pinkas, and Y. Sella.

Fairplay-secure two-party computation system. In

USENIX Security Symposium, 2004.

[58] J. Martin and M. Finnegan. What is IFTTT? How to

use If This, Then That services. Computerworld, Jan.

2019. https://www.computerworld.com/article/

3239304/what-is-ifttt-how-to-use-if-this-

then-that-services.html.

[59] X. Mi, F. Qian, Y. Zhang, and X. Wang. An empirical

characterization of IFTTT: ecosystem, usage, and

performance. In ACM SIGCOMM Conference on

Internet Measurement (IMC), 2017.

[60] Microsoft. Microsoft Power Automate — Microsoft

Power Platform.

https://flow.microsoft.com/en-us/.

[61] Microsoft Azure. Pricing - Bandwidth — Microsoft

Azure. https://azure.microsoft.com/en-us/

pricing/details/bandwidth/.

[62] Microsoft Azure. Pricing - Linux Virtual Machines —

Microsoft Azure.

https://azure.microsoft.com/en-us/pricing/

details/virtual-machines/linux/.

[63] MongoDB. MongoDB.

https://pymongo.readthedocs.io/en/stable/,

2019.

[64] B. Parno, C. Gentry, J. Howell, and M. Raykova.

Pinocchio: Nearly practical veriﬁable computation. In

IEEE Symposium on Security and Privacy (S&P), May

2013.

[65] T. P. Projects. Flask.

https://palletsprojects.com/p/flask/, 2019.

[66] Raejeanne Skillern. Intel SGX Data Protections Now

Available for Mainstream Cloud Platforms. Intel IT

Peer Network, Feb. 2019.

[67] R. L. Rivest, L. Adleman, and M. L. Dertouzos. On

data banks and privacy homomorphisms. Foundations

of secure computation, 4(11):169–180, 1978.

[68] J. H. Saltzer and M. D. Schroeder. The protection of

information in computer systems. Proceedings of the

IEEE, 63(9):1278–1308, 1975.

[69] Samsung. Samsung SmartThings. Add a little

smartness to your things.

https://www.smartthings.com/.

[70] S. Setty, S. Angel, T. Gupta, and J. Lee. Proving the

correct execution of concurrent services in

zero-knowledge. In USENIX Symposium on Operating

Systems Design and Implementation (OSDI), 2018.

[71] E. M. Songhori, S. U. Hussain, A.-R. Sadeghi,

T. Schneider, and F. Koushanfar. TinyGarble: Highly

compressed and scalable sequential garbled circuits. In

IEEE Symposium on Security and Privacy (S&P), 2015.

[72] M. Surbatovich, J. Aljuraidan, L. Bauer, A. Das, and

L. Jia. Some recipes can do more than spoil your

appetite: Analyzing the security and privacy risks of

IFTTT recipes. In International World Wide Web

Conference (WWW), 2017.

[73] Uber. When you’re on your way home, set your Nest

thermostat. https://ifttt.com/applets/

q2FtiLCe-when-you-re-on-your-way-home-

set-your-nest-thermostat.

[74] B. Ur, M. Pak Yong Ho, S. Brawner, J. Lee,

S. Mennicken, N. Picard, D. Schulze, and M. L.

Littman. Trigger-action programming in the wild: An

analysis of 200,000 IFTTT recipes. In CHI Conference

on Human Factors in Computing Systems, 2016.

[75] J. Valinsky. 7 of the biggest hacks in history. CNN

Business, July 2019.

https://www.cnn.com/2019/07/30/tech/

biggest-hacks-in-history/index.html.

[76] M. Walﬁsh and A. J. Blumberg. Verifying

computations without reexecuting them: From

theoretical possibility to near practicality.

Communications of the ACM, 58(2), Jan. 2015.

[77]

Weather Underground. Get a daily 6:00 AM email with

the weather report. https:

//ifttt.com/applets/Zv56ZXwR-get-a-daily-

6-00-am-email-with-the-weather-report.

[78]

R. Xu, Q. Zeng, L. Zhu, H. Chi, X. Du, and M. Guizani.

Privacy leakage in smart homes and its mitigation:

IFTTT as a case study. IEEE Access, 7:63457–63471,

2019.

[79] H. Yang. Authlib. https:

//docs.authlib.org/en/latest/index.html,

2017.

[80] A. C. Yao. Protocols for secure computations. In

Symposium on Foundations of Computer Science

(FOCS), 1982.

[81] S. Zahur and D. Evans. Obliv-C: A language for

extensible data-oblivious computation. Cryptology

ePrint Archive, Report 1153, 2015.

[82]

S. Zahur, M. Rosulek, and D. Evans. Two halves make

a whole. In Annual International Conference on the

Theory and Applications of Cryptographic Techniques

(EUROCRYPT), 2015.

[83] K. Zetter. Ex-Googler allegedly spied on user e-mails,

chats. Wired, Sept. 2010.

https://www.wired.com/2010/09/google-spy/.

[84] L. Zhou, L. Wang, Y. Sun, and P. Lv. BeeKeeper: A

blockchain-based IoT system with secure storage and

homomorphic computation. IEEE Access,

6:43472–43488, 2018.