{"id":"3639b24b-e868-4357-a805-23cee9604ab9","arxiv_id":"2412.11640","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"SeSeMI shows that SGX enclaves can be reused and packed inside a standard serverless platform to serve encrypted model inference with lower latency and lower memory cost than existing TEE-serverless designs.","lead":"SeSeMI is a serverless model-inference system that keeps machine learning models and user requests encrypted inside Intel SGX enclaves, with a key service, an enclave runtime, and a model packer layered on Apache OpenWhisk. Its three components aim to provide low latency and low cost on a cloud the model owner does not trust.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Access revocation is missing: warm SeMIRT enclaves serve requests from cached keys without re-checking KeyService (Algorithm 2, lines 6-10), so a revoked user remains served until the enclave dies; the 'unauthorized users cannot see models and requests' claim holds only under an unstated…","rationale":"I read the paper in good faith as a systems contribution whose central claim is that SeSeMI provides confidential, access-controlled model serving on serverless platforms with low latency and cost. The most load-bearing condition for that claim is that access control is actually enforced for every request. The reader's weakest_assumption identifies exactly this: after a successful key retrieval, warm enclaves serve cached keys without re-checking KeyService, and no revocation/update operation is defined in Algorithm 1. My independent reading confirms this. Sections IV-A and IV-D promise that 'model inference is performed only if the execution is authorized by both the model owner and the user' and that KeyService 'prevents unauthorized users from using the model.' Algorithm 2's key cache bypasses this authorization on cache hits, and the lack of any revoke/delete operation in Algorithm 1 means the policy cannot even be changed, despite the implementation section claiming clients can update access control policies. This is a genuine security gap, and it directly undermines the design goal 'prevents inference executions from unauthorized model users.' I also considered two other candidate concerns. First, non-intrusiveness is softened by the need to add SGX driver mounts and aesmd flags to the OpenWhisk invoker; this affects the deployability claim but does not break the security argument, and the paper discloses the 'except for the SGX support' caveat. Second, the evaluation lacks error bars and repetition counts, which weakens performance claims but does not affect the security guarantee. The revocation gap is therefore the most load-bearing. The fix is straightforward: add an explicit revoke/update operation to KeyService and make SeMIRT re-validate access on cache hits, or clearly document a static-policy assumption with an explicit bound on warm-enclave lifetime. Until then, the verdict should remain CONDITIONAL, as the reader concluded; my analysis does not change that verdict.","tokens_in":25310,"tokens_out":6349,"duration_ms":64907,"concrete_test":"One decisive check: (1) grant user U access to model M and warm up an enclave with a request from U; (2) add a REVOKE_ACCESS procedure to KeyService that removes the corresponding ⟨Moid∥ES∥uid⟩ entry from ACM and KS_R, and invoke it; (3) send a new request from U to the same warm/hot endpoint. If the request is served using the cached keys in Algorithm 2 lines 6-10 without any KeyService interaction, revocation is not enforced and the concern lands. A stronger version of the test would instrument SeMIRT to log every KeyService call during the second request; a successful inference with zero KeyService calls confirms the gap.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central security claim is that SeSeMI prevents inference executions from unauthorized model users and that 'the cloud and unauthorized users cannot see the models and requests in the clear.' This requires access control to be enforceable at request-serving time. However, the design has no revocation or update path in KeyService: Algorithm 1 defines only USER_REGISTRATION, ADD_MODEL_KEY, GRANT_ACCESS, ADD_REQ_KEY, and KEY_PROVISIONING, with no procedure to remove or modify ACM or KS_R entries. Section V says clients can 'update access control policies', but the pseudocode and implementation do not provide this operation. Moreover, even if an update were added, Algorithm 2 lines 6-10 make a cache hit on the last ⟨uid, Moid⟩ pair the trigger for using the retained keys without contacting KeyService again. A warm or hot enclave therefore continues to serve a user whose access has been revoked until the sandbox is destroyed or the key cache is evicted. The paper never states that access policies are static for the lifetime of warm enclaves, and the openwhisk container timeout of 3 minutes (Table V) bounds how long revocation would eventually take effect only if a new instance were started. As written, the access-control guarantee is not dynamic and contradicts the stated security goal of preventing unauthorized users from obtaining inference results. This is a security-relevant correctness gap, not a matter of style or performance; it affects the core 'unauthorized users cannot see' claim.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents SeSeMI, a TEE-based confidential model inference system for serverless platforms. It introduces three components: KeyService, an enclave-based service that performs remote attestation, manages model and request decryption keys, and enforces access-control lists; SeMIRT, an SGX enclave runtime that caches decrypted models and keys, supports concurrent requests, and distinguishes cold, warm, and hot invocation paths; and FnPacker, which packs requests to infrequently used models onto shared endpoints. The system is implemented on Apache OpenWhisk and evaluated with three models (MobileNet, ResNet101, DenseNet121), two inference frameworks (TFLM, TVM), and both SGX1 and SGX2 clusters. The paper claims that SeSeMI achieves four goals: confidentiality against an untrusted cloud and unauthorized users, low latency, low cost, and no intrusive changes to the existing serverless infrastructure.","tokens_in":25567,"tokens_out":7421,"duration_ms":69878,"significance":"The contribution is potentially significant. The paper identifies real challenges in combining SGX with serverless computing and proposes concrete, reasonably engineered mechanisms to address them. The evaluation is extensive: micro-benchmarks of serving stages, single-node and multi-node tests, MMPP workloads, cost integrals, and SGX1/SGX2 comparisons. The code is open-sourced, and the design of SeMIRT's caching and FnPacker's scheduling is described in enough detail to be reproducible. The main weakness is security: the access-control argument is informal and, as written, does not support dynamic revocation, which is required by the stated security goal. This is a central, load-bearing gap rather than a presentation issue.","major_comments":[{"comment":"The security claim that SeSeMI \"prevents inference executions from unauthorized model users\" (Section III) is not supported for dynamic access-control policies. Algorithm 1 defines only USER_REGISTRATION, ADD_MODEL_KEY, GRANT_ACCESS, ADD_REQ_KEY, and KEY_PROVISIONING; it contains no operation to revoke or update ACM or KS_R entries. Section V nevertheless states that clients can \"update access control policies\" with KeyService, but no such operation is specified in the pseudocode or described in the implementation. Even if an update mechanism were added, Algorithm 2 lines 6-10 make a cache hit on the last (Moid, uid) pair the trigger for using retained keys without contacting KeyService again, so a warm or hot enclave would continue to serve a user whose access has been revoked until the sandbox is destroyed or the cache is evicted. The paper never states that access-control policies are static for the lifetime of warm enclaves; the OpenWhisk container timeout of 3 minutes (Table V) only bounds how long revocation would eventually take effect if a new instance were started. This is a security-relevant correctness gap in the central claim, not a stylistic issue, and should be fixed either by explicitly stating a static-policy assumption or by adding a revocation/expiry/re-check mechanism and evaluating its cost.","section":"IV-A, IV-B, IV-D, V"},{"comment":"The claim in Section IV-D that SeMIRT \"avoids potential problems from sharing an enclave across different models and users by running only one model and serving requests from one user per enclave\" is not enforced by Algorithm 2. The pseudocode uses a single global key cache KC and caches only the last pair of decryption keys, but there is no lock, admission control, or check that prevents two concurrent EC_MODEL_INF calls with different uid values from executing in the same enclave. Under concurrency, one thread can overwrite KC while another thread is still processing a request with a previously fetched key, so requests from different users can be in flight in the same enclave at overlapping times. This contradicts the stated isolation rationale and can cause requests to be decrypted with the wrong key or to fail. The paper should either specify the concurrency control around KC and the user-association invariant, or restrict the one-user-per-enclave claim to the sequential-processing configuration described in Section V.","section":"IV-B and IV-D"}],"minor_comments":[{"comment":"The text says clients can \"update access control policies\" with KeyService, but Algorithm 1 and the implementation section define no such update operation; please align the prose with the pseudocode or add the missing operation.","section":"V"},{"comment":"Figures 11-14 report average latencies and cost integrals without error bars, confidence intervals, or repetition counts; please state the number of runs and the observed variance so the comparative claims can be assessed.","section":"VI"},{"comment":"The Iso-reuse baseline is implemented by the authors from the descriptions in prior work because no source code is available; please state whether this implementation has been validated and whether it is released, since baseline fidelity directly affects the performance comparisons in Figures 12 and 13.","section":"VI, Baselines"},{"comment":"The notation for the key cache is underspecified: KC is described as \"last pair of decryption keys,\" but the condition on line 6 tests membership of \"Moid∥uid\"; please clarify the exact structure of KC and the locking discipline around it.","section":"IV-B, Algorithm 2"},{"comment":"The non-intrusiveness claim should be qualified: Appendix F shows that OpenWhisk invokers must be configured to mount the SGX driver and aesmd into containers, which is a platform-level configuration change even if no source-code modification to the serverless platform is required.","section":"III and Appendix F"},{"comment":"The Native baseline is omitted from Figure 12a without an explanatory note; please add a caption statement that Native saturates below the plotted request-rate range.","section":"VI-B, Figure 12a"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is within scope for a systems/security venue and the open-source release is a genuine strength. The main gap is security-relevant and should be addressed before publication; I do not see evidence of problematic novelty overlap with prior work, and the related-work placement is fair. The dynamic-revocation issue is fixable within the manuscript's scope by stating a static-policy assumption or by adding a revocation mechanism, so I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my take. SeSeMI is a solid systems paper: it builds a working TEE-based serverless inference stack on OpenWhisk, evaluates it carefully across two SGX generations, two frameworks, three models, and shows meaningful latency and cost wins. The three components—KeyService as an attestation bridge, SeMIRT's hot-path reuse, FnPacker's model packing—are each known in spirit, but the combination and the inference-specific tuning are new relative to S-FaaS, Clemmy, and Reusable Enclaves. The evaluation is a real strength: micro-benchmarks, single-node, multi-node, cost integrals, and a clear breakdown of where the overhead goes. They even open-source the code.\n\nThe soft spots are real but concentrated. The revocation gap is the one I'd flag first. Algorithm 1 has no revoke or update operation; Algorithm 2 caches the key pair and on a cache hit never contacts KeyService again. So if an owner revokes a user's access, a warm enclave keeps serving that user until the container dies. Section V mentions clients can 'update access control policies,' but the pseudocode and implementation don't back that up. This is a genuine security-correctness gap in the 'unauthorized users cannot see the models and requests' claim. It's fixable—add a revoke/update path and make cache hits re-check, or state clearly that access policy is assumed static for the enclave lifetime. But as written, the claim overreaches.\n\nThe other issues are minor. The performance eval has no error bars or repetition counts; the numbers look plausible but I'd want confidence intervals before trusting the 21x headline. The 'non-intrusive' claim is mostly fair, but they do have to touch the invoker to mount SGX driver and aesmd, which is more than zero platform configuration. The Iso-reuse baseline is author-implemented, which is fine, but baseline fidelity is hard to verify.\n\nWho's this for? Systems folks working on confidential computing or serverless ML will get real value. The design is clean, the measurements are informative, and the artifact is open. It deserves a serious referee, but the referee should push for the revocation fix or an explicit static-policy statement, plus repeated runs.","headline":"A genuinely useful confidential-serverless-inference system with a missing revocation path that undercuts the headline security claim.","tokens_in":26137,"tokens_out":2015,"would_cite":true,"duration_ms":19614,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SeSeMI claims that serverless model inference can keep models and user requests secret from an untrusted cloud by adding three non-intrusive components to existing serverless platforms, with low latency and cost.","keywords":["serverless computing","model inference","Intel SGX","trusted execution environment","access control","confidential computing","remote attestation","OpenWhisk"],"falsifier":"Revoke a user's access by removing her entries from ACM and KS_R at KeyService, then send a fresh request from that user to a warm endpoint that has previously served her; if the endpoint answers without contacting KeyService, the claimed access-control enforcement is disproven.","tokens_in":1658,"feed_emoji":"🔒","tokens_out":1872,"duration_ms":69386,"temperature":0.7,"pith_summary":"This paper sets out to show that serverless model inference can protect both the model and the user's request data from an untrusted cloud provider, without forcing the provider to change its serverless platform. The proposed system, SeSeMI, adds three components on top of a standard serverless stack: a key service that attests enclaves and enforces access control, an enclave runtime that reuses cached keys, models, and runtimes across requests, and a packer that lets multiple models share an instance under sparse traffic. The authors argue that trusted hardware alone does not solve the problem, because users cannot directly attest ephemeral serverless instances and TEE setup is expensive; their design delegates attestation to an always-on service and amortizes setup cost. On Apache OpenWhisk with two inference frameworks, they report that hot requests, which reuse an already-loaded enclave, run at nearly the speed of plaintext serving, and that concurrent request handling cuts per-request memory and monetary cost.","feed_headline":"SeSeMI keeps AI models and user data secret on serverless clouds","feed_subtitle":"Three add-on components let SGX enclaves serve requests at near-plaintext speed while cutting memory cost.","key_machinery":"The central mechanism is KeyService, an always-on attestation bridge enclave that holds identity keys, model keys, request keys, and access-control tuples, and provisions keys to a SeMIRT enclave only after mutual remote attestation confirms the enclave's MRENCLAVE matches the policy. The companion mechanism is SeMIRT's key/model/runtime cache inside the enclave, which turns cold starts into warm or hot invocations; FnPacker then decides which endpoint should receive each request based on pending work and idle state.","core_discovery":"SeSeMI's central claim is that confidentiality and access control for model serving can be achieved on an unmodified serverless platform by moving trust to a KeyService enclave and by making the serving enclaves stateful. The model owner and each user first attest KeyService and register long-term keys; the owner encrypts the model and the user encrypts each request, and KeyService releases the decryption keys only to a SeMIRT enclave whose hardware-measured identity (MRENCLAVE) matches the access-control records ACM and KS_R. SeMIRT then caches the retrieved key pair, the decrypted model, and the initialized inference runtime, so a hot invocation skips enclave initialization, remote attestation, key retrieval, model loading, and runtime initialization, leaving only decryption, inference, and result encryption. FnPacker routes requests to endpoints that can switch among infrequently used models. The evaluation reports that hot invocations give up to 21x speedup over cold ones, that SeMIRT keeps latency near the model-execution cost, and that sharing enclave threads reduces memory cost by roughly 48-59% for TVM models under a bursty MMPP workload.","pith_inferences":["The access-control guarantee is only as strong as the assumption that policies do not change: KeyService has no revocation procedure, and a warm enclave that has cached a key pair will keep serving the user without recontacting KeyService.","The same three-component pattern — an attestation bridge, a state-reusing enclave runtime, and a model packer — could generalize to other TEE platforms and to stateful serverless workloads beyond inference.","If TEE cold-start and attestation costs drop in future hardware, the latency advantage of hot invocations will shrink; the durable contribution may become the attestation delegation and access-control design rather than the caching runtime.","FnPacker's scheduling is heuristic; a predictive version could estimate model-switch costs from arrival statistics and choose between exclusive and packed endpoints accordingly."],"forward_implications":["A cloud provider can offer confidential model serving by adding SGX support and deploying SeSeMI's three components, with no changes to the serverless control plane.","Hot requests, which hit a warm enclave with the right model and keys cached, run at near-plaintext speed, so interactive users and bursty traffic see low latency.","Under infrequent and unpredictable per-model traffic, FnPacker's packing reduces the number of cold starts and the model owner's memory-based bill.","Because SeMIRT shares one enclave across concurrent requests, the memory footprint per request drops, allowing smaller instance budgets.","On SGX2 hardware the bottleneck shifts from enclave memory to CPU, so inference frameworks that reduce compute or memory traffic gain more."],"supporting_citations":[{"why":"Defines SGX enclaves and remote attestation, the hardware isolation and identity primitive SeSeMI relies on.","marker":"[7]"},{"why":"Specifies the RA-TLS protocol that SeSeMI uses to turn an attestation report into a secure channel for key provisioning.","marker":"[29]"},{"why":"Provides the SGX RA-TLS implementation used for attestation between clients, KeyService, and SeMIRT.","marker":"[58]"},{"why":"The S-FaaS prior work that SeSeMI benchmarks against, since it also integrates SGX into serverless but lacks fine-grained access control.","marker":"[14]"},{"why":"Clemmys, whose enclave-reuse optimization is the basis of the Iso-reuse baseline in the evaluation.","marker":"[16]"},{"why":"Introduces serverless model inference costs and SLO-aware serving, motivating the latency and cost targets.","marker":"[1]"},{"why":"The model-serving case study that supplies the realistic request workloads used in SeSeMI's evaluation.","marker":"[2]"},{"why":"The MLPerf workload patterns from which FnPacker's mixed Poisson/interactive-session evaluation is built.","marker":"[13]"},{"why":"The adaptive-batching workload generator used alongside [1,2] for the MMPP evaluation.","marker":"[60]"}],"fun_headline_variants":["SeSeMI: secure serverless inference with SGX, near-plaintext speed","SGX enclaves serve models on unmodified serverless platforms","Hot serverless enclaves skip attestation for 21x faster inference","SeSeMI cuts memory cost 48-59% while securing model inference"],"cache_read_input_tokens":28160,"weakest_assumption_plain":"Access control is enforced only when keys are first fetched: after a SeMIRT enclave has cached a user's decryption keys, it serves that user's subsequent requests without rechecking KeyService, so the system silently assumes that access-control policies never change during an enclave's lifetime.","fun_headline_variants_meta":{"raw":{"variants":["SeSeMI: secure serverless inference with SGX, near-plaintext speed","SGX enclaves serve models on unmodified serverless platforms","Hot serverless enclaves skip attestation for 21x faster inference","SeSeMI cuts memory cost 48-59% while securing model inference"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000505,"raw_usage":{"total_tokens":2529,"prompt_tokens":1077,"completion_tokens":1452,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":693,"completion_tokens_details":{"reasoning_tokens":1371}},"tokens_in":693,"tokens_out":1452,"duration_ms":10367,"temperature":1.0,"reasoning_tokens":1371,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T14:44:40.516668+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Revoke a user's access by removing her entries from ACM and KS_R at KeyService, then send a fresh request from that user to a warm endpoint that has previously served her; if the endpoint answers without contacting KeyService, the claimed access-control enforcement is disproven.","supporting_citations":[{"cited_title":"Intel sgx explained,","cited_arxiv_id":null,"evidence_quote":"Defines SGX enclaves and remote attestation, the hardware isolation and identity primitive SeSeMI relies on."},{"cited_title":"sgx-ra-tls,","cited_arxiv_id":null,"evidence_quote":"Provides the SGX RA-TLS implementation used for attestation between clients, KeyService, and SeMIRT."},{"cited_title":"S-faas: Trustworthy and accountable function-as-a-service using intel sgx,","cited_arxiv_id":null,"evidence_quote":"The S-FaaS prior work that SeSeMI benchmarks against, since it also integrates SGX into serverless but lacks fine-grained access control."},{"cited_title":"Clemmys: Towards secure remote execution in faas,","cited_arxiv_id":null,"evidence_quote":"Clemmys, whose enclave-reuse optimization is the basis of the Iso-reuse baseline in the evaluation."},{"cited_title":"Mark: Exploiting cloud services for cost-effective, slo-aware machine learning inference serving,","cited_arxiv_id":null,"evidence_quote":"Introduces serverless model inference costs and SLO-aware serving, motivating the latency and cost targets."},{"cited_title":"Serverless data science - are we there yet? a case study of model serving,","cited_arxiv_id":null,"evidence_quote":"The model-serving case study that supplies the realistic request workloads used in SeSeMI's evaluation."},{"cited_title":"Mlperf inference benchmark,","cited_arxiv_id":null,"evidence_quote":"The MLPerf workload patterns from which FnPacker's mixed Poisson/interactive-session evaluation is built."},{"cited_title":"Batch: Machine learning inference serving on serverless platforms with adaptive batching,","cited_arxiv_id":null,"evidence_quote":"The adaptive-batching workload generator used alongside [1,2] for the MMPP evaluation."}],"review_version":1}