Pith. sign in

REVIEW 4 major objections 6 minor 50 references

LURK-T: Limited Use of Remote Keys With Added Trust in TLS 1.3

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read LURK-T is a TLS 1.3 server delegation design that isolates long-term credentials in a TEE-backed crypto service while keeping the client-facing TLS protocol unchanged.

desk verdict Solid, artifact-backed TLS 1.3 delegation design whose remote-deployment security claim rests on an unproven E-CS channel assumption and whose abstract overstates performance under SGX mitigations. read the letter →

arxiv 2506.12026 v1 pith:N7JEGHZT submitted 2025-05-21 cs.CR

Behnam Shobiri , Sajjad Pourali , Daniel Migault , Ioana Boureanu , Stere Preda , Mohammad Mannan , Amr Youssef This is my paper · ORCID
classification cs.CR
keywords lurk-tcryptocryptographicserverservicetrustaddedallows
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Websites backed by content delivery networks often share their TLS private keys with the CDN's edge servers, which are spread around the world. If any edge server is compromised, the long-term key can be stolen and used to impersonate the site. LURK-T splits the TLS 1.3 server into two pieces: the Engine, which talks to browsers and handles most of the connection logic, and the Crypto Service, which lives inside a trusted execution environment and holds the private key. The Engine asks the Crypto Service to do only specific jobs, such as signing the handshake transcript or deriving session secrets. The client sees an ordinary TLS 1.3 server, so no browser changes are needed.

The design has two main variants. In the active variant, the Crypto Service also generates the ephemeral Diffie-Hellman keys, which lets it enforce perfect forward secrecy and keep resumption keys confidential. In the passive variant, the Engine generates those keys for better performance, but the Crypto Service no longer controls forward secrecy. The paper presents computational security theorems, reported in high-level form, and a ProVerif symbolic verification that the three parties agree on the handshake. The implementation uses Intel SGX and OpenSSL, with roughly 3,800 lines of code in the enclave.

Measured overhead depends heavily on cipher suite and SGX security mitigations. In the default SGX configuration, HTTPS overhead is near zero for 1 MB files across all tested cipher suites. With SGX mitigations enabled, most cipher suites still show large overhead at 1 MB. The paper's abstract states no noticeable overhead for files greater than 1 MB without this caveat.

Extended reading notes

Core claim

The paper claims LURK-T is "a generic, provably secure and efficient decoupling of the TLS1.3 server into a cryptographic core called LURK-T Crypto Service (CS), and a component called LURK-T Engine (E) which securely queries this core from anywhere it may reside, and communicates with a classical TLS Client (C)." It further claims that "LURK-T suffers no degradation in security compared to TLS 1.3, including attaining perfect forward secrecy." If correct, the TLS 1.3 private key can be held inside a TEE and used on behalf of a distributed engine without modifying TLS 1.3, without changing the client, and with no loss of security relative to standard TLS 1.3.

Load-bearing premise

The security theorems assume that the Crypto Service inside a TEE cannot be corrupted and that the Engine-Crypto Service channel is a secure ACCE protocol or that the two are collocated. Section III-B states "We assume CS is trustworthy. ... TEE and its interfaces cannot be corrupted," and every theorem in Section VII-A2 repeats the hypothesis that the protocol between E and CS is a secure ACCE protocol or they are collocated. If an adversary can break the TEE, compromise key provisioning, or subvert the E-CS channel, the claimed guarantees no longer hold. The ProVerif model idealizes this channel as a private channel rather than verifying the actual LURK-T channel.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes LURK-T, a framework that decouples a TLS 1.3 server into a LURK-T Engine (E) and a LURK-T Crypto Service (CS) running inside a Trusted Execution Environment (TEE). The authors define an API for the E–CS interaction, implement CS in Intel SGX with an OpenSSL integration, measure performance for various cipher suites and CS configurations, and present both computational security theorems in a 3(S)ACCE model and a ProVerif symbolic verification. The central claims are that LURK-T provides a generic, provably secure, and efficient decoupling of the TLS 1.3 server without modifying TLS 1.3 or the client, that it preserves TLS 1.3 security including perfect forward secrecy, and that from the client perspective the overhead is not noticeable for files larger than 1 MB.

Significance. If the claimed results are fully established, LURK-T would be a valuable contribution: it offers a server-controlled delegation mechanism for TLS 1.3 that works with unmodified clients and covers a spectrum of deployment choices (collocated or remote CS, active or passive CS, keyless operation, session resumption). The paper has concrete strengths: its implementation and ProVerif files are open-sourced, the design considers several realistic variants with different security/efficiency trade-offs, and the performance study covers many cipher suites and includes measurements with SGX mitigations enabled. However, the computational security results as stated are weakened by a circular hypothesis and by the absence of proof material, the remote-deployment security claim rests on an unverified E–CS channel assumption, and the abstract's efficiency claim is overstated for mitigation-enabled SGX. These issues are substantial but appear fixable with a major revision.

major comments (4)
  1. [Section VII-A2] The four security results (entity-authentication, channel security, accountability, trusted key-binding) each include as a hypothesis that 'the two protocols (the one between C and E, and the one between E and CS) ensure 3(S)ACCE mixed entity authentication [8]' in the non-collocated case. Since 3(S)ACCE mixed entity authentication is itself a composed security property encompassing entity authentication, assuming it is tantamount to assuming a large part of the conclusions these theorems state. As written, the results are circular and do not constitute a proof that LURK-T provides 3(S)ACCE security from primitive TLS assumptions. The paper should state theorems over the underlying TLS 1.3 and E–CS channel primitives and then prove the composed properties, in the style of Bhargavan et al. [8].
  2. [Section VII-A2 and Section IV-A] For the non-collocated deployment, all theorems assume 'the protocol between E and CS is a secure ACCE protocol'. The paper never proves that the actual E–CS channel—the LURK-T request/response messages (SInitCertificateVerify and related exchanges) carried over the pre-established mutually authenticated TLS channel described in Section IV-A—is a secure ACCE protocol, nor that it provides the '3(S)ACCE mixed entity authentication' required by the theorems. In the ProVerif analysis (Section VII-B2), the E–CS channel is modeled as a private channel, so the symbolic result also bypasses the real channel. The central claim that LURK-T does not degrade TLS 1.3 security in remote-CS deployments is therefore not established. Please either provide a composition proof for the actual E–CS protocol, or explicitly state this as an assumption limiting the claim to the collocated case.
  3. [Abstract and Section VI-D, Table IV(b)] The abstract's claim that HTTPS servers using LURK-T 'have no noticeable overhead when serving files greater than 1MB' is contradicted by the mitigation-enabled SGX measurements in Table IV(b): for 1MB files, six of seven cipher suites show overheads between 38.2% and 85.2% (RSA-3072 69.1%, RSA-4096 85.2%, P-256 41.7%, P-384 60.4%, Ed448 38.2%). The text itself notes that for most cipher suites the negligible-overhead pivot occurs only above 1MB. The abstract and contributions should qualify the claim to the default SGX configuration and to the specific cipher suites and configurations that achieve it.
  4. [Section VII-A2] No proof sketches or proof references accompany the theorem statements; the paper says 'we now state our cryptographic guarantees' and gives only the If–then statements. Since the paper's headline contribution is a 'provably secure' decoupling, the manuscript must include the proofs (or a precise pointer to a full version with complete proofs) for each theorem, including the security reductions and the treatment of the freshness function φ as a non-programmable PRF.
minor comments (6)
  1. [Section VII-A2] The heading 'Cryptogtaphic proofs' contains a typo; it should read 'Cryptographic proofs'.
  2. [Section VI-A] The methodology states that 'we took the average time after performing 10,000 handshakes', but no standard deviation or confidence intervals are reported for any of the performance numbers; variance should be reported, especially for the small overheads claimed.
  3. [Table IV(b)] The table header contains typos: 'Mitigation-enbaled' should be 'Mitigation-enabled', and '(ld and S)' should be '(ld and SRDBS)'.
  4. [Section VII-A2] The channel security result statement is grammatically tangled: ''LURK-T with DHE-passiveCS' in EC-DHE mode are entity-authentication secure in the 3(S)ACCE model attain channel security in the 3(S)ACCE model.' It should be separated into two distinct claims or rephrased for clarity.
  5. [Abstract and Section VII] The abstract's claim of 'including attaining perfect forward secrecy' is not explicitly tied to a formal result in Section VII; the computational theorems do not mention PFS, and the ProVerif query in Figure 7 does not state a PFS property. Please indicate which result establishes PFS or soften the claim.
  6. [Section IV-A] The freshness function is referred to as both φ and ϕ in the same paragraph; use one symbol consistently throughout.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity; security claims are conditional and compositional, with the remote E-CS channel left as an explicit assumption rather than a proven component.

full rationale

The paper's derivation chain is not circular in a way that makes its conclusions equal to its inputs. The computational theorems in Section VII-A2 are stated as conditional compositions: assuming TLS 1.3 security, a secure ACCE protocol (or collocation) for the E-CS channel, 3(S)ACCE mixed entity authentication for the two sub-protocols, secure signatures/AEAD, and a non-programmable PRF freshness function, the paper derives 3(S)ACCE entity authentication, channel security, accountability, and trusted key-binding for LURK-T. These hypotheses are standard modular assumptions, not re-statements of the conclusions, and the paper is explicit about them. The ProVerif analysis in Section VII-B2 lifts external TLS 1.3 models [36], [6] and machine-checks a new 3-party agreement query; modeling the E-CS channel as a private channel is an explicit idealization of the stated ACCE assumption, not a fitted parameter or a renamed conclusion. The self-citations ([11], [32], [8], [12], [21]) provide prior context, the LURK API draft, the 3(S)ACCE model, and the PRF notion, but the TLS 1.3-specific decomposition, implementation, and verification are performed in this paper. The main caveat—that remote, non-collocated deployments inherit the unproven assumption that the actual LURK-T E-CS channel is a secure ACCE protocol—is a rigor/assumption gap and a correctness risk, which the paper states explicitly and partially mitigates in Section VIII, but it does not make the derivation circular.

Assumptions & free parameters 0 free parameters · 7 assumptions · 0 invented entities

The framework relies on standard TLS 1.3 security assumptions, on the 3(S)ACCE composition model, and on domain assumptions about TEE integrity, secure key provisioning, and a secure Engine-Crypto Service channel. No experimental parameters are fitted; the design introduces no new physical or mathematical entities.

assumptions (7)
  • domain assumption TLS 1.3 is secure with respect to unilateral entity authentication.
    Invoked as the base assumption in every computational theorem in Section VII-A2; the proof is conditional on this external result about RFC 8446.
  • domain assumption The Engine-Crypto Service protocol is a secure ACCE protocol, or the two are collocated.
    Used in all theorems in Section VII-A2; the paper specifies a pre-established mutually authenticated encrypted channel but does not provide a computational proof of the actual LURK-T channel.
  • domain assumption The freshness function is a non-programmable PRF.
    Required for channel security, accountability, and trusted key-binding results in Section VII-A2, referencing [12].
  • domain assumption The TEE and its interfaces cannot be corrupted, and runtime remote attestation is available.
    Section III-B states CS is trustworthy and the TEE threat model assumes an uncorruptible TEE; trusted key-binding additionally requires runtime remote attestation per Section VII-A2.
  • standard math The signature scheme, hash function, and AEAD used in TLS 1.3 are secure in their threat models.
    Standard cryptographic assumptions listed as hypotheses in the theorems of Section VII-A2.
  • domain assumption Key provisioning to the enclave is secure.
    Section III-B states the private key must be securely provisioned to CS, for example via Blindfold or secure enclave provisioning; if provisioning fails, credential protection fails.
  • domain assumption The ProVerif model's private channel between E and CS is an accurate idealization of the real E-CS channel.
    Section VII-B2 models the secure E-CS channel as a private channel inaccessible to the Dolev-Yao attacker; the actual channel is expected to be TLS terminating inside the enclave, which is not symbolically modeled in detail.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LURK-T: Limited Use of Remote Keys With Added Trust in TLS 1.3." pith.science (2026). https://pith.science/paper/N7JEGHZT

@misc{pith2026250612026,
  author       = {Pith},
  title        = {Pith review of: LURK-T: Limited Use of Remote Keys With Added Trust in TLS 1.3},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/N7JEGHZT}},
  note         = {Machine review of arXiv:2506.12026}
}
read the original abstract

In many web applications, such as Content Delivery Networks (CDNs), TLS credentials are shared, e.g., between the website's TLS origin server and the CDN's edge servers, which can be distributed around the globe. To enhance the security and trust for TLS 1.3 in such scenarios, we propose LURK-T, a provably secure framework which allows for limited use of remote keys with added trust in TLS 1.3. We efficiently decouple the server side of TLS 1.3 into a LURK-T Crypto Service (CS) and a LURK-T Engine (E). CS executes all cryptographic operations in a Trusted Execution Environment (TEE), upon E's requests. CS and E together provide the whole TLS-server functionality. A major benefit of our construction is that it is application agnostic; the LURK-T Crypto Service could be collocated with the LURK-T Engine, or it could run on different machines. Thus, our design allows for in situ attestation and protection of the cryptographic side of the TLS server, as well as for all setups of CDNs over TLS. To support such a generic decoupling, we provide a full Application Programming Interface (API) for LURK-T. To this end, we implement our LURK-T Crypto Service using Intel SGX and integrate it with OpenSSL. We also test LURK-T's efficiency and show that, from a TLS-client's perspective, HTTPS servers using LURK-T instead a traditional TLS-server have no noticeable overhead when serving files greater than 1MB. In addition, we provide cryptographic proofs and formal security verification using ProVerif.

Figures

Figures reproduced from arXiv: 2506.12026 by the authors.

Figure 1
Figure 1. LURK-T entities: a TLS client C (a regular web browser), a LURK-T TLS Engine E, and a LURK-T TLS Crypto Service CS (both part of a third-party hosting provider), and a key provisioning server (under the content owner’s control). with even discussions at the IETF to deprecate that mode [1]. “LURK-T with DHE-active CS” – TLS (EC)DHE mode. Following Figure 2a, C initiates the TLS key exchange with E by sending a Client… view at source ↗
Figure 2
Figure 2. The two variants of LURK-T instantiated with TLS 1.3 in (EC)DHE Mode [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. CS deployment use cases V. SYSTEM IMPLEMENTATION In this section, we describe our implementation6 of CS and E based on OpenSSL. CS centralizes the cryptographic oper￾6Available from https://github.com/lurk-t/ [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Messages between E and CS for the (EC)DHE mode. * designates an optional exchange depending on the CS configuration (EC)DHE shared secret using C’s (EC)DHE public key and the S’s (EC)DHE private key – that is kept secret by CS. This is im￾plemented with our get_ecdhe f…
Figure 5
Figure 5. Figure 5: KEX LURK-T TLS relative overhead over OpenSSL [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 7
Figure 7. Figure 7: Agreement query between C, E, CS w.r.t. symbolic verification. All this is complementary to the results in Section VII-A2. This section is structured as follows. First, we report on a ProVerif-verification of TLS 1.3 which we lifted from TLS 1.3 pre-standardisation (i.…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 47 canonical work pages

  1. [8]

    Content delivery over TLS: a cryptographic analysis of keyless SSL,

    K. Bhargavan, I. Boureanu, P . Fouque, C. Onete, and B. Richard, “Content delivery over TLS: a cryptographic analysis of keyless SSL,” inIEEE EuroS&P, 2017, pp. 1–16

    work page 2017

  2. [1]

    [Online]

    RFC 9257. [Online]. Available: https://www.rfc- editor.org/rfc/rfc9257.txt

    work page

  3. [2]

    SCONE: secure linux containers with intel SGX,

    S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe, J. Lind, D. Muthukumaran, D. O’Keeffe, M. Stillwell, D. Goltzsche, D. M. Eyers, R. Kapitza, P . R. Pietzuch, and C. Fetzer, “SCONE: secure linux containers with intel SGX,” inUSENIX OSDI, 2016, pp. 689–703

    work page 2016

  4. [3]

    TaLoS: Secure and Transparent TLS Termination inside SGX Enclaves,

    P .-L. Aublin, F. Kelbert, D. O’Keeffe, D. Muthukumaran, C. Priebe, J. Lind, R. Krahn, C. Fetzer, D. Eyers, and P . Pietzuch, “TaLoS: Secure and Transparent TLS Termination inside SGX Enclaves,” 2017

    work page 2017

  5. [4]

    Delegated Credentials for TLS,

    R. Barnes, S. Iyengar, N. Sullivan, and E. Rescorla, “Delegated Credentials for TLS,” Internet Engineering Task Force, Internet-Draft draft-draft-ietf-tls-subcerts, Jan. 2021, work in Progress. [Online]. Avail- able: https://datatracker.ietf.org/doc/html/draft-draft-ietf-tls-subcerts

    work page 2021

  6. [5]

    Hardware-Enabled Security: Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases,

    M. Bartock, M. Souppaya, R. Savino, T. Knoll, U. Shetty, M. Cherfaoui, R. Y eluri, A. Malhotra, and K. Scarfone, “Hardware-Enabled Security: Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases,” inDraft NISTIR 8320, may 2021. [Online]. Available: https://doi.org/10.6028/NIST.IR.8320-draft

    work page doi:10.6028/nist.ir.8320-draft 2021

  7. [6]

    V erified models and reference implementations for the TLS 1.3 standard candidate,

    K. Bhargavan, B. Blanchet, and N. Kobeissi, “V erified models and reference implementations for the TLS 1.3 standard candidate,” in2017 IEEE Symposium on Security and Privacy (SP), 2017, pp. 483–502

    work page 2017

  8. [7]

    A Formal Treatment of Accountable Proxying over TLS,

    K. Bhargavan, I. Boureanu, A. Delignat-Lavaud, P .-A. Fouque, and C. Onete, “A Formal Treatment of Accountable Proxying over TLS,” inProceedings of IEEE S&P. IEEE, 2018

    work page 2018

Show all 50 references
  1. [9]

    Modeling and verifying security protocols with the applied Pi calculus and ProV erif,

    B. Blanchet, “Modeling and verifying security protocols with the applied Pi calculus and ProV erif,”F ound. Trends Priv . Secur ., vol. 1, no. 1-2, pp. 1–135, 2016

    2016

  2. [10]

    ÆPIC leak: Architecturally leaking uninitialized data from the microarchitecture,

    P . Borrello, A. Kogler, M. Schwarzl, M. Lipp, D. Gruss, and M. Schwarz, “ÆPIC leak: Architecturally leaking uninitialized data from the microarchitecture,” inUsenix Security Symposium, Boston, MA, USA, Aug. 2022

    2022

  3. [11]

    LURK: server-controlled TLS delegation,

    I. Boureanu, D. Migault, S. Preda, H. A. Alamedine, S. Mishra, F. Fieau, and M. Mannan, “LURK: server-controlled TLS delegation,” inIEEE TrustCom, 2020, pp. 182–193

    2020

  4. [12]

    On the pseudorandom function assumption in (secure) distance-bounding protocols - prf-ness alone does not stop the frauds!

    I. Boureanu, A. Mitrokotsa, and S. V audenay, “On the pseudorandom function assumption in (secure) distance-bounding protocols - prf-ness alone does not stop the frauds!” inLATINCRYPT, vol. 7533, 2012, pp. 100–120

    2012

  5. [13]

    Hardening of cryptographic operations through the use of secure enclaves,

    A. Brandao, J. Resende, and R. Martins, “Hardening of cryptographic operations through the use of secure enclaves,”Computers & Security, p. 102327, 2021

    2021

  6. [14]

    L VI: hijacking transient execution through microarchitectural load value injection,

    J. V . Bulck, D. Moghimi, M. Schwarz, M. Lipp, M. Minkin, D. Genkin, Y . Y arom, B. Sunar, D. Gruss, and F. Piessens, “L VI: hijacking transient execution through microarchitectural load value injection,” in2020 IEEE Symposium on Security and Privacy. IEEE, 2020, pp. 54–72

    2020

  7. [15]

    Iago attacks: why the system call API is a bad untrusted RPC interface,

    S. Checkoway and H. Shacham, “Iago attacks: why the system call API is a bad untrusted RPC interface,” inASPLOS. ACM, 2013, pp. 253–264

    2013

  8. [16]

    Cisco visual networking index: forecast and methodology, 2017-2022,

    Cisco, “Cisco visual networking index: forecast and methodology, 2017-2022,” 2017. [Online]. Available: https://s3.amazonaws.com/ media.mediapost.com/uploads/CiscoForecast.pdf

    2017

  9. [17]

    TeeRex: Discovery and exploitation of memory corruption vulnerabilities in SGX enclaves,

    T. Cloosters, M. Rodler, and L. Davi, “TeeRex: Discovery and exploitation of memory corruption vulnerabilities in SGX enclaves,” inUSENIX Security Symposium, 2020, pp. 841–858

    2020

  10. [18]

    A survey of symbolic methods in computational analysis of cryptographic systems,

    V . Cortier, S. Kremer, and B. Warinschi, “A survey of symbolic methods in computational analysis of cryptographic systems,”J. Autom. Reason., vol. 46, no. 3-4, pp. 225–259, 2011. [Online]. Available: https://doi.org/10.1007/s10817-010-9187-9

    2011 doi

  11. [19]

    Intel SGX explained,

    V . Costan and S. Devadas, “Intel SGX explained,”IACR Cryptol. ePrint Arch., vol. 2016, p. 86, 2016. [Online]. Available: http://eprint.iacr.org/2016/086

    2016

  12. [20]

    A survey and analysis of tls interception mechanisms and motivations,

    X. d. C. de Carnavalet and P . C. van Oorschot, “A survey and analysis of tls interception mechanisms and motivations,”arXiv preprint arXiv:2010.16388, 2020

    2010 arXiv

  13. [21]

    Blindfold: Keeping private keys in PKIs and CDNs out of sight,

    H. Galal, M. Mannan, and A. Y oussef, “Blindfold: Keeping private keys in PKIs and CDNs out of sight,”Computers & Security, vol. 118, Jul. 2022

    2022

  14. [22]

    Achieving keyless cdns with conclaves,

    S. Herwig, C. Garman, and D. Levin, “Achieving keyless cdns with conclaves,” inUSENIX Security Symposium, 2020, pp. 735–751

    2020

  15. [23]

    Affected Processors: Transient Execution Attacks & Related Security Issues by CPU,

    “Affected Processors: Transient Execution Attacks & Related Security Issues by CPU,”Intel Security Center, apr 2021. [Online]. Available: https://software.intel.com/security-software-guidance/processors- affected-transient-execution-attack-mitigation-product-cpu-model

    2021

  16. [24]

    Intel QuickAssist Technology (Intel QA T) and OpenSSL-1.1.0: Performance,

    Intel Corporation, “Intel QuickAssist Technology (Intel QA T) and OpenSSL-1.1.0: Performance,” 2018. [Online]. Available: https: //01.org/sites/default/files/downloads/intelr-quickassist-technology/ 337003-001-intelquickassisttechnologyandopenssl-110.pdf

    2018

  17. [25]

    intel/intel-sgx-ssl,

    ——, “intel/intel-sgx-ssl,” 2021. [Online]. Available: https://github.com/intel/intel-sgx-ssl

    2021

  18. [26]

    Intel Software Guard Extensions: EPID Provisioning and Attestation Services ,

    S. Johnson, V . Scarlata, C. Rozas, E. Brickell, and F. Mckeen, “Intel Software Guard Extensions: EPID Provisioning and Attestation Services ,”Intel White P aper, 2016. [Online]. Available: https://software.intel.com/content/dam/develop/public/us/en/ documents/ww10-2016-sgx-pr...

    2016

  19. [27]

    SRBDS - Special Register Buffer Data Sampling,

    “SRBDS - Special Register Buffer Data Sampling,”The Linux kernel user’s and administrator’s guide, The kernel development community. [Online]. Available: https://www.kernel.org/doc/html/latest/admin- guide/hw-vuln/special-register-buffer-data-sampling.html

  20. [28]

    Integrating Intel SGX Remote Attestation with Transport Layer Security,

    T. Knauth, M. Steiner, S. Chakrabarti, L. Lei, C. Xingand, and M. Vij, “Integrating Intel SGX Remote Attestation with Transport Layer Security,”Intel White P aper, jul 2019. [Online]. Available: https://arxiv.org/pdf/1801.05863.pdf

    2019 arXiv

  21. [29]

    When HTTPS meets CDN: A case of authentication in delegated service,

    J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, “When HTTPS meets CDN: A case of authentication in delegated service,” in2014 IEEE Symposium on Security and Privacy, 2014, pp. 67–82

    2014

  22. [30]

    Glamdring: Automatic application partitioning for intel SGX,

    J. Lind, C. Priebe, D. Muthukumaran, D. O’Keeffe, P . Aublin, F. Kelbert, T. Reiher, D. Goltzsche, D. M. Eyers, R. Kapitza, C. Fetzer, and P . R. Pietzuch, “Glamdring: Automatic application partitioning for intel SGX,” in2017 USENIX Annual T echnical Conference, 2017, pp. 285–298

    2017

  23. [31]

    Understanding TEE containers, easy to use? hard to trust,

    W. Liu, H. Chen, X. Wang, Z. Li, D. Zhang, W. Wang, and H. Tang, “Understanding TEE containers, easy to use? hard to trust,”CoRR, vol. abs/2109.01923, 2021. IEEE TRANSACTIONS ON NETWORK SCIENCE AND ENGINEERING, VOL. 11, NO. 6, NOVEMBER/DECEMBER 2024 15

    2021 arXiv

  24. [32]

    LURK Extension version 1 for (D)TLS 1.3 Authentication,

    D. Migault, “LURK Extension version 1 for (D)TLS 1.3 Authentication,” Internet Engineering Task Force, Internet-Draft draft- draft-mglt-lurk-tls13, Jan. 2021, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/html/draft-draft-mglt-lurk-tls13

    2021

  25. [33]

    Downfall: Exploiting speculative data gathering,

    D. Moghimi, “Downfall: Exploiting speculative data gathering,” in Usenix Security Symposium, Anaheim, CA, USA, Aug. 2023

    2023

  26. [34]

    Multi-context TLS (mcTLS): Enabling secure in-network functionality in TLS,

    D. Naylor, K. Schomp, M. V arvello, I. Leontiadis, J. Blackburn, D. R. L ´opez, K. Papagiannaki, P . R. Rodr´ıguez, and P . Steenkiste, “Multi-context TLS (mcTLS): Enabling secure in-network functionality in TLS,” inACM SIGCOMM, 2015, pp. 199–212

    2015

  27. [35]

    SGX-LKL: securing the host OS interface for trusted execution,

    C. Priebe, D. Muthukumaran, J. Lind, H. Zhu, S. Cui, V . A. Sartakov, and P . R. Pietzuch, “SGX-LKL: securing the host OS interface for trusted execution,”CoRR, vol. abs/1908.11143, 2019

    1908 arXiv

  28. [36]

    [Online]

    “RefTLS,” 2018. [Online]. Available: https://github.com/Inria- Prosecco/reftls

    2018

  29. [37]

    CROSSTALK: Speculative Data Leaks Across Cores Are Real,

    H. Ragab, A. Milburn, K. Razavi, H. Bos, and C. Giuffrida, “CROSSTALK: Speculative Data Leaks Across Cores Are Real,” 2020. [Online]. Available: https://download.vusec.net/papers/crosstalksp21.pdf

    2020

  30. [38]

    The Transport Layer Security (TLS) Protocol V ersion 1.3,

    E. Rescorla, “The Transport Layer Security (TLS) Protocol V ersion 1.3,” RFC 8446, Aug. 2018. [Online]. Available: https://rfc-editor.org/rfc/RFC8446.txt

    2018

  31. [39]

    Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),

    Y . Sheffer, P . Saint-Andre, and T. Fossati, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” RFC 9325, Nov. 2022. [Online]. Available: https://www.rfc-editor.org/info/RFC9325

    2022

  32. [40]

    Panoply: Low-TCB Linux applications with SGX enclaves,

    S. Shinde, D. L. Tien, S. Tople, and P . Saxena, “Panoply: Low-TCB Linux applications with SGX enclaves,” inNDSS, 2017

    2017

  33. [41]

    An analysis of TLS handshake proxying,

    D. Stebila and N. Sullivan, “An analysis of TLS handshake proxying,” inIEEE TrustCom/BigDataSE/ISP A, Helsinki, Finland, 2015, pp. 279–286

    2015

  34. [42]

    TS-Perf: General performance measurement of trusted execution environment and rich execution environment on Intel SGX, Arm TrustZone, and RISC-V Keystone,

    K. Suzaki, K. Nakajima, T. Oi, and A. Tsukamoto, “TS-Perf: General performance measurement of trusted execution environment and rich execution environment on Intel SGX, Arm TrustZone, and RISC-V Keystone,”IEEE Access, vol. 9, pp. 133 520–133 530, 2021

    2021

  35. [43]

    Intel® QuickAssist Technology with Intel Key Protection Technology in Intel Server Platforms Based on Intel Xeon Processor Scalable Family,

    H. Tadepalli, “Intel® QuickAssist Technology with Intel Key Protection Technology in Intel Server Platforms Based on Intel Xeon Processor Scalable Family,” inWhite P aper. Intel Corporation, 2017. [Online]. Available: https://www.aspsys.com/images/solutions/hpc- processors/int...

    2017

  36. [44]

    A practical intel SGX setting for linux containers in the cloud,

    D. J. Tian, J. I. Choi, G. Hernandez, P . Traynor, and K. R. B. Butler, “A practical intel SGX setting for linux containers in the cloud,” in ACM CODASPY, 2019, pp. 255–266

    2019

  37. [45]

    Graphene-sgx: A practical library OS for unmodified applications on SGX,

    C. Tsai, D. E. Porter, and M. Vij, “Graphene-sgx: A practical library OS for unmodified applications on SGX,” in2017 USENIX Annual T echnical Conference, USENIX ATC, 2017, 2017, pp. 645–658

    2017

  38. [46]

    SoK: SGX.Fail: How stuff get eXposed,

    S. van Schaik, A. Seto, T. Y urek, A. Batori, B. AlBassam, C. Garman, D. Genkin, A. Miller, E. Ronen, and Y . Y arom, “SoK: SGX.Fail: How stuff get eXposed,” https://sgx.fail, 2022

    2022

  39. [47]

    STYX: a trusted and accelerated hierarchical SSL key management and distribution system for cloud based CDN application,

    C. Wei, J. Li, W. Li, P . Y u, and H. Guan, “STYX: a trusted and accelerated hierarchical SSL key management and distribution system for cloud based CDN application,” inACM SoCC, 2017, pp. 201–213

    2017

  40. [48]

    sgx-perf: A performance analysis tool for intel SGX enclaves,

    N. Weichbrodt, P . Aublin, and R. Kapitza, “sgx-perf: A performance analysis tool for intel SGX enclaves,” inACM/IFIP Middleware, 2018, pp. 201–213

    2018

  41. [49]

    Regaining lost cycles with hotcalls: A fast interface for SGX secure enclaves,

    O. Weisse, V . Bertacco, and T. M. Austin, “Regaining lost cycles with hotcalls: A fast interface for SGX secure enclaves,” inProceedings of the 44th Annual International Symposium on Computer Architecture, 2017, pp. 81–93

    2017

  42. [50]

    Montsalvat: Intel SGX shielding for graalvm native images,

    P . Y uhala, J. M´en´etrey, P . Felber, V . Schiavoni, A. Tchana, G. Thomas, H. Guiroux, and J. Lozi, “Montsalvat: Intel SGX shielding for graalvm native images,” inACM/IFIP Middleware, 2021, pp. 352–364. Behnam Shobiriis a security researcher at Tigera wher he is researching ...

    2021

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.