Architecting Trigger-Action Platforms for Security, Performance and Functionality

Architecting Trigger-Action Platforms for Security, Performance and Functionality

Speakers: Deepak Sirone Jegan

Conference: NDSS Symposium

YouTube: (no public video)

Overview

Trigger-Action Platforms (TAPs) like IFTTT, Zapier, and Microsoft Power Automate have become indispensable tools for end-users, enabling seamless automation of interactions between diverse web services and devices. These platforms, which can range from simple applets like "add a new spreadsheet row, compute data, send to Slack" to complex workflows, act as centralized hubs managing privileged access to vast amounts of sensitive user data and devices. Despite their widespread adoption and utility, current TAP architectures inherently demand complete and unconditional trust from users regarding their secure operation.

This reliance on an untrustworthy cloud service presents a critical security vulnerability. Experience has repeatedly shown that cloud services are susceptible to compromise, whether through application-level vulnerabilities, exploits in the underlying cloud software stack, or malicious insiders. An attacker who compromises a TAP cloud service could gain unfettered access to sensitive data and devices for millions of users, leading to OAuth token theft, integrity violations, and severe privacy breaches. This growing concern has even led some major services, such as GMail, to become reluctant to interface with TAPs, highlighting the urgent need for a more secure paradigm.

TAPDance is a novel re-architected Trigger-Action Platform designed to address this fundamental trust deficit. The core vision behind TAPDance is to execute user-created applets while guaranteeing that attackers cannot manipulate their execution or steal user data, even if the underlying TAP cloud service is entirely compromised. TAPDance achieves this by leveraging tailored use of Trusted Execution Environments (TEEs), specifically RISC-V Keystone enclaves, to minimize the Trusted Computing Base (TCB). Beyond its robust security guarantees—ensuring confidentiality and integrity of program execution—TAPDance also demonstrates superior performance, outperforming baseline TAP implementations in terms of latency and throughput, while supporting a significant fraction of real-world applets.

Background

[▶ Watch: Introduction to TAPs, trust issues, and TAPDance solution (0:00)]()

Trigger-Action Platforms (TAPs) function as cloud services designed to connect disparate web services and Internet of Things (IoT) devices. They operate on a trigger-compute-action paradigm: an event (trigger) occurs, the platform performs some computation, and then initiates an operation (action). Services typically expose APIs for both triggers and actions, with a compatibility or shim layer often translating service-specific APIs into a format understandable by the TAP. Given their distributed nature and large scale, current TAPs necessitate users to place absolute trust in the platform's secure operation, a trust that TAPDance aims to eliminate.

TAPDance fundamentally re-architects this model by employing RISC-V Enclaves with Keystone. Enclaves provide an attested, isolated execution environment, ensuring data confidentiality and code integrity even against malicious supervisor-mode software. Keystone, built upon RISC-V's Physical Memory Protection (PMP) registers, offers highly customizable enclaves managed by a small Security Monitor (SM). Crucially, each enclave possesses a unique code-identity—a cryptographic hash of its code combined with the SM's hash, signed by the processor's private key—which enables remote attestation. This customizability is pivotal for TAPDance, allowing it to minimize its trusted hardware and software base to only the essential components.

The Threat Model for TAPDance assumes the TAP itself is entirely untrusted. This encompasses realistic threats such as application-level vulnerabilities, exploits within the cloud software stack, or malicious insiders. The focus is on remote attackers with no physical access to datacenter machines. An attacker is presumed to have extensive capabilities: arbitrarily manipulating applet binaries, full control over the operating system running the TAP software, knowledge of trigger and action service API details, access to OAuth tokens for user services, and the ability to modify, replay, or drop messages. Malicious users attempting to compromise the TAP or access other users' data are also considered. Conversely, the user's client device (smartphone, laptop) is assumed to be trusted and acts as a root-of-trust for TAPDance. Similarly, the trigger and action services (e.g., Google Calendar, Slack) are trusted to adhere to specified protocols and not collude. The underlying processor package running TAPDance is also assumed to be secure.

Based on this threat model, TAPDance establishes several Security Goals: (1) Confidentiality of Trigger and Action Data, preventing sensitive user data from being exposed to the untrustworthy TAP or other malicious entities. (2) Integrity of Applet Execution, ensuring applets run without tampering. (3) Applet Execution Freshness, guaranteeing applets execute only in response to a fresh triggering event, thwarting replays. (4) OAuth Token Misuse Prevention, preventing the untrusted TAP from abusing OAuth tokens. It explicitly states Non-goals such as denial-of-service attacks, network traffic analysis, or network side channels. Functionally, TAPDance aims to support existing applets (via a restricted TypeScript subset), preserve current programming workflows, enable offline execution (no client device required during runtime), and necessitate minimal modifications to trigger/action services.

TAPDance stands apart from Alternative Approaches. Running computations at the edge (directly on trigger/action services) would drastically increase complexity and attack surface. Cryptographic approaches like eTAP or Walnut, utilizing garbled circuits, incur high overhead and support only limited applet types. The "Big Enclave" approach, which would place the entire TAP runtime and a TypeScript interpreter within an enclave, would result in an unacceptably large and complex TCB, negating the benefits of TEEs. TAPDance offers a superior balance by intelligently restricting the scope of trusted computation.

Key Findings

[▶ Watch: Selecting RISC-V Keystone for minimal TEE (3:00)]()

The research behind TAPDance presents several pivotal findings that challenge conventional wisdom in securing distributed automation platforms:

• Robust Security Guarantees: TAPDance successfully achieves strong security properties, including confidentiality of sensitive trigger and action data, integrity of applet execution, freshness against replay attacks, and prevention of OAuth token misuse, even when the entire TAP cloud infrastructure is untrusted.
• Applets as Pure Computations: The core insight is that most real-world applets can be modeled as pure computations that receive input, transform it, and produce output, without requiring complex I/O or system interactions. This enables compiling applets directly to machine code and running only minimal support libraries within the TEE.
• Minimalist TEE Architecture: By leveraging RISC-V Keystone enclaves, which provide simple, hardware-backed isolation via PMP registers, and extending its Security Monitor with TAP-specific services (e.g., centralized nonce management, secure time), TAPDance drastically minimizes the trusted hardware and software base.
• Significant TCB Reduction: TAPDance achieves a 5.2x reduction in the software TCB required for applet execution compared to a Node.js-based interpreted baseline. The TAPDance enclave components (including runtime, TLS, JSON parsing, SM) total approximately 213 KLOC, whereas the Node.js baseline (including V8) is approximately 1044 KLOC. This reduction is critical for security assurance.
• High Applet Compatibility: Despite using a restricted subset of TypeScript, the TAPDance compiler successfully compiled 94% (642 out of 682) of real user applets from the minTAP dataset. Most of the remaining 6% could be easily rewritten, demonstrating the practical expressiveness of the pure computation model.
• Performance Superiority: Counter-intuitively, TAPDance not only provides robust security but also outperforms non-secure interpreted baselines. It achieved 32% lower latency and 33% higher throughput on average, primarily due to running compiled machine code and the minimal overhead of enclave context switches.
• Efficient Memory Utilization: Applet enclaves in TAPDance are remarkably lightweight, consuming only 2.1 MB of memory, compared to 39.3 MB for the Node.js interpreter. This low memory footprint allows a single server to keep approximately 62,000 applets warm in memory, significantly reducing cold-start costs.

Technical Deep Dive

[▶ Watch: Centralized nonce management for applet freshness (3:30)]()

The fundamental design principle of TAPDance is to confine the pure computational logic of an applet within an attested enclave, leaving all other components outside the TCB. This is complemented by an end-to-end encryption scheme where trigger and action services communicate encrypted data directly with the applet enclave, using keys known only to them and the enclave.

The architecture comprises several key components:

1. Trusted Client: This is the user's smartphone app or browser extension, serving as the root-of-trust. It embeds the code-identity of the TAPDanceManager enclave and the public key of the RISC-V processor. It handles OAuth token negotiation, applet creation and compilation, encryption of applets, and establishes secret keys with trigger/action endpoints and the TAPDanceManager enclave via attested TLS.
2. RISC-V Enclaves with Keystone: Selected for its small, contiguous isolated memory segments provided by Physical Memory Protection (PMP) registers, Keystone is ideal for pure-function applets. Its customizability allows for extensions to the Security Monitor.
3. Security Monitor (SM): The standard Keystone SM is extended with four critical services for TAPDance: a secure time source (guaranteeing no preemption during time fetching), a secure source of randomness for nonce generation, a centralized nonce management service (allowing the untrusted OS to request fresh nonces and applets to verify their freshness, ensuring a nonce is verified only once by a specific enclave), and a mechanism to terminate long-running applets.
4. TAPDanceManager Enclave: A long-running, attested enclave whose code-identity is pre-baked into the trusted client. It verifies the attestation of applet enclaves, supplies decryption keys (kapp, kus, kas) to them, and securely stores user credentials and applet key material using sealed storage. It acts as a trusted intermediary for secure key distribution.
5. Untrusted TAP OS: This component manages OAuth tokens (which are rendered useless for direct access due to encryption), receives encrypted trigger data, launches and destroys applet enclaves, and provides a networking stack. Its inability to misuse OAuth tokens or replay trigger data is central to TAPDance's security.
6. Applet Enclave: This is where user-created computations execute as compiled binary code. Upon launch, the untrusted OS initializes the enclave, which then runs a decryption stub. This stub reports the enclave's code-identity to the TAPDanceManager for attestation. Once verified, the TAPDanceManager supplies the necessary decryption keys. The applet enclave then decrypts and executes the user's code, utilizing a minimal runtime for JSON parsing, mathematical operations, date/time functions, and an attested TLS library for secure communication.
7. Time-keeping Enclave: An attested enclave that synchronizes its clock with NTP, allowing the SM to update processor time registers securely.
8. Trigger/Action Shims: These are minor modifications to existing service endpoints. The trigger shim encrypts data using a user- and service-specific key (kus) and manages an event queue with nonces. The action service uses its user- and service-specific key (kas) to decrypt data and verify its freshness before executing the action.
9. TypeScript-to-RISC-V Compiler: A custom LLVM-based compiler translates a restricted subset of TypeScript (supporting static typing and built-in methods, but avoiding complex features like I/O or eval()) into RISC-V assembly, making it suitable for enclave execution.

TAPDance Execution Protocol

The protocol involves three main phases, utilizing OCalls for enclave-to-OS communication and Attested TLS for secure communication between trusted parties.

A. User Bootstrapping:

The user's trusted client embeds the TAPDanceManager's code-identity and the RISC-V processor's public key. During service signup, the client generates user-specific symmetric encryption keys (kus for triggers, kas for actions) and securely transmits them. The client also creates a username/password on the TAP by interacting with the TAPDanceManager enclave over an attested TLS connection, which stores these credentials encrypted with a sealing key bound to its code-identity.

B. Creating an Applet:

Through the trusted client, the user develops an applet, which is then compiled to RISC-V assembly using the custom LLVM-based compiler. The client encrypts the applet binary with an AES GCM key (kapp) and attaches an unencrypted decryption stub. This package is sent to the untrusted TAP. Simultaneously, the client sends kapp, kus, kas, and the applet's code-identity to the TAPDanceManager via attested TLS, where it's securely stored. OAuth tokens are negotiated for the untrusted TAP, but these are rendered useless for an attacker due to end-to-end encryption.

C. Running an Applet (Execution Protocol):

1. Trigger Event: An event (e.g., new spreadsheet row) occurs. The trigger service sends an HTTP(S) callback, including the trigger identity, to the untrusted TAP.
2. Applet Launch (Cold Start): The untrusted TAP allocates memory, loads the applet and runtime binaries, and initializes the applet enclave via the SM.

• Attestation & Key Retrieval: The applet enclave's decryption stub requests its report from the SM and sends it to the TAPDanceManager over attested TLS. The TAPDanceManager verifies the report against the expected code-identity. If valid, it retrieves kapp, kus, kas for this applet and sends them back to the applet enclave over attested TLS. The decryption stub then decrypts the applet code using kapp.
• Trigger Data Retrieval: In parallel, the untrusted TAP obtains a fresh nonce from the SM. It then requests trigger data from the trigger service, including the OAuth token, nonce, and trigger identity. The trigger service saves this nonce and returns the encrypted trigger data (Enc(kus, Data Timestamp Nonce)). The untrusted TAP forwards this encrypted data to the applet enclave.

1. Applet Execution:

• The applet enclave decrypts the trigger data using kus. If decryption fails, it errors.
• If successful, the applet extracts the nonce and asks the SM to verify its freshness. It also verifies the timestamp against the SM's secure time source.
• If all checks pass, the applet executes its logic on the trigger data, producing action data.
• It then encrypts this action data using kas, including an action-nonce (from SM's randomness) and a timestamp.
• The applet enclave returns this encrypted action data to the untrusted TAP, which forwards it to the action service.
• The action service decrypts the data using kas, verifies the timestamp and action-nonce, and finally executes the action.

For a Warm Start, if the applet enclave is already in memory, the attestation and key retrieval steps are skipped, significantly reducing latency.

Security Analysis

TAPDance achieves its security goals through several mechanisms:

• Confidentiality of Trigger and Action Data: The trigger shim only sends encrypted trigger data using kus, preventing the untrusted TAP from stealing it. The action service only performs actions if the payload is encrypted under a valid kas. Keys (kus, kas) are accessible solely to the user's trusted client, trigger/action shims, and the TAPDanceManager enclave, and only after successful attestation for applet enclaves.
• Integrity of Applet Execution: Hardware-assisted isolation via RISC-V PMP registers provides isolation between enclaves, fault isolation of untrusted enclaves from the OS, and inverse sandboxing protecting the enclave from the OS. The trigger shim encrypts API call parameters, and the TAPDanceManager only provides keys after verifying the applet's code-identity.
• Single Execution Per Trigger Event and Freshness of Data: To prevent replay attacks, the trigger shim associates the first nonce from the TAP with new trigger data. The SM fails verification for reused nonces. Encrypted trigger data includes a timestamp, verified by the applet enclave against the SM's secure time source, ensuring at most once semantics.
• Limiting OAuth Token Misuse: While the untrusted TAP holds OAuth tokens, they are useless for direct access because services only respond with encrypted data or accept encrypted payloads. Service providers map tokens to the TAP service identity, maintaining encryption checks.
• TEE Side Channels: Keystone enclaves do not share page table state with the untrusted OS, mitigating controlled-channel attacks. Timing resistance is enabled in WolfSSL. Cache attacks are noted as future work, with cache partitioning as a potential solution.

Demo / Proof of Concept

[▶ Watch: Detailed threat model against untrusted TAP (5:00)]()

While a live demonstration was not explicitly described, the research paper includes a comprehensive Performance Evaluation which serves as the concrete proof of concept for TAPDance's viability and claims.

The TAPDance system was implemented and evaluated on a StarFive VisionFive single board computer, a RISC-V U74 core machine comparable to a Raspberry Pi. This hardware choice reflects the current availability of RISC-V development boards, with the design principles being applicable to future server-grade RISC-V chips. Trigger and action services were simulated on CloudLab machines. For comparative analysis, a baseline TAP system was implemented using Node.js v14.8.0 on the VisionFive, mirroring current interpreted TAP architectures.

The custom TypeScript-to-RISC-V compiler was built upon StaticScript and LLVM-IR. Within the enclaves, WolfSSL was used for TLS communication, and RapidJSON for efficient JSON parsing.

A key aspect of the proof of concept was the Functionality Evaluation of applet support. Using a dataset of 682 real user applets from the minTAP dataset, TAPDance's TypeScript compiler successfully compiled 642 out of 682 applets (94%). Of the 39 that did not compile, 37 could be easily rewritten to conform to the supported TypeScript subset. Only 2 applets made extensive use of unsupported user-defined objects, classes, or indexing. This demonstrates that the "pure computation" abstraction adopted by TAPDance is expressive enough for a significant majority of real-world applets, validating its practical applicability. The correctness of compiled applets was further verified by comparing their outputs with those from the Node.js interpreter.

The performance and security claims of TAPDance were rigorously tested, showing:

• TCB Size Reduction: A 5.2x reduction in software TCB size for applet execution (213 KLOC for TAPDance enclaves vs. 1044 KLOC for Node.js baseline).
• Performance: A 32% lower latency and 33% higher throughput on average compared to the interpreted baseline, with warm-start applet execution times of 0.58 ms (compared to 0.62 ms for Node.js).
• Memory Usage: A significantly lower memory footprint for applet enclaves at 2.1 MB, enabling a single server to keep approximately 62,000 applets warm in memory.

These results collectively serve as a robust proof of concept, demonstrating that TAPDance successfully delivers on its promises of enhanced security, high functionality, and improved performance.

Defensive Implications

[▶ Watch: Key security and functionality goals (6:00)]()

The advent of TAPDance offers profound defensive implications for both users and operators of Trigger-Action Platforms, shifting the security paradigm from inherent trust to verifiable guarantees.

For TAP Users:

• Enhanced Data Confidentiality: Users gain a strong assurance that their sensitive trigger and action data, such as financial transactions, personal communications, or device states, remain confidential even if the TAP cloud provider's infrastructure is compromised. This protection extends to OAuth tokens, which an attacker cannot misuse for direct access to user services.
• Guaranteed Applet Integrity: Users can be confident that their applets execute precisely as intended, free from manipulation by malicious insiders or external attackers. This prevents malicious code injection or tampering that could lead to incorrect actions or data exfiltration.
• Replay Protection: The freshness guarantees ensure that applets respond only to legitimate, current trigger events, preventing an attacker from replaying old events to cause unintended or repetitive actions.

For TAP Operators and Service Providers:

• Reduced Trust Burden and Liability: TAP operators can significantly reduce the trust burden placed on their users and mitigate their own liability in the event of a cloud breach. By offering a platform that guarantees confidentiality and integrity, they can attract more users and sensitive integrations, potentially revitalizing trust in TAPs.
• Secure Integration with Sensitive Services: Service providers (e.g., banks, healthcare providers) can integrate with TAPs more securely, knowing that their data will be encrypted end-to-end and processed within a trusted execution environment, even if the TAP itself is untrusted.
• Minimized TCB for Auditing: The drastic reduction in the Trusted Computing Base (TCB) simplifies security auditing and verification. A smaller TCB means fewer lines of code and hardware components need to be meticulously scrutinized for vulnerabilities.
• Adoption of TEE-based Architectures: TAP operators should consider migrating their core applet execution environments to TEEs like RISC-V Keystone enclaves. This involves architecting applets as pure computations suitable for compilation and isolated execution.
• Implementation of Attestation and Key Management: Robust remote attestation and secure key management protocols, similar to those in TAPDance, are crucial for establishing trust with client devices and securely distributing encryption keys.
• Modification of Service Shims: Trigger and action service providers should implement or update their shims to support end-to-end encryption with user-specific keys and enforce nonce/timestamp checks, ensuring data integrity and freshness from their end.
• Consideration for Scalability: While TAPDance addresses core security, operators must consider the scalability of components like the TAPDanceManager enclave using techniques like chain replication, as well as strategies for key updates and protection against message re-ordering in action services.
• Future Work on Publicly Influenced Triggers: For applets triggered by publicly influenced events (e.g., email content), operators should consider further research into verifying compiled code for vulnerabilities to prevent crafted inputs from exploiting applets and leaking keys.

Overall, TAPDance provides a concrete blueprint for building a new generation of automation platforms where security is architectural rather than merely procedural, fostering greater trust and enabling broader, more sensitive applications.

Key Takeaways

• Current Trigger-Action Platforms (TAPs) demand complete user trust and are inherently vulnerable to cloud compromises, leading to data theft and integrity violations.
• TAPDance re-architects TAPs using RISC-V Keystone enclaves to provide strong confidentiality, integrity, and freshness guarantees for applet execution and user data, even with an untrusted TAP cloud service.
• The core innovation is modeling applets as pure computations, enabling compilation to machine code and execution within a minimal Trusted Computing Base (TCB), which is 5.2x smaller than traditional interpreted approaches.
• TAPDance not only enhances security but also significantly improves performance, demonstrating 32% lower latency and 33% higher throughput compared to a Node.js baseline, while using minimal memory (2.1 MB per applet enclave).
• The system exhibits high compatibility, successfully compiling 94% of real-world applets from a standard dataset, validating its practical applicability for a wide range of automation tasks.
• Defenders and TAP operators should consider adopting TEE-based architectures like TAPDance to reduce trust burdens, enhance data privacy, ensure execution integrity, and mitigate liability in an increasingly complex threat landscape.

About the Speaker(s)

Deepak Sirone Jegan is the presenter of this research on "Architecting Trigger-Action Platforms for Security, Performance and Functionality" at the NDSS Symposium. The transcript indicates their role in presenting this work, but does not provide further biographical details such as their specific title, affiliation, or other research contributions.