Microbenchmarking Cloud Cryptographic Workloads for Privacy-Preserving Healthcare IoT

Technical Summary: Microbenchmarking Cloud Cryptographic Workloads for Privacy-Preserving Healthcare IoT

Problem Statement
Cryptographic operations are fundamental to cloud security architectures, particularly for healthcare Internet of Things (IoT) applications like Remote Patient Monitoring (RPM). These systems generate sensitive physiological data that requires secure transmission, storage, and real-time analysis to support anomaly detection and predictive decision-making. While Function-as-a-Service (FaaS) platforms (e.g., AWS Lambda, Azure Functions) offer scalability and reduced operational overhead, the performance trade-offs of integrating core cryptographic workloads with cloud-native Key Management Services (KMS) within these serverless environments remain poorly understood.

Existing literature often relies on synthetic workloads, excludes integrated KMS, or fails to account for the dynamic nature of FaaS (e.g., cold starts, ephemeral execution, and resource constraints). This lack of empirical data creates a significant gap for healthcare developers who must balance strict regulatory compliance (e.g., HIPAA), low-latency requirements for critical health events, and cost efficiency when selecting programming languages, CPU architectures, and memory configurations.

Methodology
The authors conducted a comprehensive microbenchmarking study to evaluate the performance of core cryptographic workloads across AWS and Azure FaaS platforms. The experimental design utilized Infrastructure-as-Code (IaC) to ensure reproducibility and consistency.

• Workloads: The study tested SHA HMAC generation, AES encryption/decryption, Elliptic Curve Cryptography (ECC) signature generation/verification, and RSA encryption/decryption.
• Integration: All operations were performed using the respective cloud providers' native KMS (AWS KMS and Azure Key Vault) to reflect realistic deployment scenarios, including envelope encryption where applicable.
• Variables: The evaluation spanned:
  • Cloud Providers: AWS Lambda and Azure Functions.
  • Programming Languages: Rust, Go, Python, Java, C#, and TypeScript.
  • CPU Architectures: x86_64 and Arm64 (where supported).
  • Memory Configurations: Ranging from 128 MB to 3008 MB (AWS) and up to 1500 MB (Azure).
• Execution: A custom Python script orchestrated HTTP requests with a standardized 4-kilobyte JSON payload to trigger cryptographic functions. Metrics were collected for both cold starts (initial invocation) and warm starts (subsequent invocations), capturing execution time, memory consumption, and cost.

Key Contributions

1. Comprehensive Analysis: The paper provides a multi-dimensional analysis of cryptographic workload implementation across multiple programming languages, CPU architectures, and memory configurations on AWS and Azure, specifically using FaaS paradigms with integrated KMS.
2. Custom Methodology: The authors propose and implement a reproducible microbenchmarking framework tailored for serverless cryptographic evaluation, addressing the limitations of prior studies that relied on HTTP endpoints or synthetic data without KMS integration.
3. Optimization Insights: The study identifies optimal configurations for cryptographic workloads, offering evidence-based guidance on balancing execution speed, throughput, and cost efficiency for healthcare IoT applications.

Results and Findings
The study achieved a 100% success rate across all tests and yielded several key findings regarding performance determinants:

• Memory Allocation: Increasing memory allocation consistently reduced execution times across all languages and architectures, though the marginal gains diminished beyond specific thresholds. Lower memory configurations (e.g., 128 MB) offered the highest cost efficiency but introduced higher latency, particularly for complex operations like RSA decryption.
• Architecture (x86_64 vs. Arm64):
  • Arm64 demonstrated superior performance in cold-start scenarios, exhibiting lower initialization overhead and faster startup times across most workloads.
  • x86_64 generally outperformed Arm64 in warm-start scenarios, especially with higher memory allocations, leveraging resources more effectively once initialized.
• Programming Languages:
  • AWS: Python 3.11 consistently delivered the fastest execution times and often the best cost-efficiency. Rust was a close competitor in raw speed but excelled in memory efficiency, consuming significantly less peak memory than Python or C#.
  • Azure: C# demonstrated superior performance in most cryptographic workloads, attributed to the tight integration of the .NET runtime within the Azure platform.
  • Java: Consistently exhibited the weakest performance in both execution time and memory consumption, largely due to JVM initialization overhead, particularly during cold starts.
• Cost Efficiency: The most cost-effective configurations often involved balancing execution time with memory allocation rather than selecting the highest available memory. For instance, Rust on 128 MB memory configurations provided highly economical profiles for AES operations.
• Provider Differences: AWS Lambda showed lower variance in execution times compared to Azure Functions, which exhibited significant fluctuations, particularly during cold starts. Azure's dynamic memory allocation strategy, while convenient, introduced performance unpredictability compared to AWS's explicit memory configuration.

Significance
The paper claims that its findings provide critical, evidence-based insights for developers and system architects designing secure healthcare IoT systems. By systematically analyzing the interplay between runtime environments, hardware architectures, and cryptographic operations, the study enables stakeholders to make informed decisions that mitigate latency and cost risks without compromising security.

Specifically, the research supports the development of secure, efficient, and scalable RPM systems. It highlights that optimal configurations are context-dependent: for instance, utilizing Arm64 for cold-start-heavy workloads or leveraging C# on Azure for low-latency requirements. The study concludes that holistic testing and benchmarking are essential to identify the optimal configuration for specific cryptographic workloads, ensuring that patient data remains protected while enabling real-time clinical decision-making. Future work is suggested to explore higher memory allocations (up to 10,240 MB on AWS) to further understand performance impacts on memory-intensive operations.