pith. sign in

arxiv: 2511.13641 · v2 · submitted 2025-11-17 · 💻 cs.CR

It's a Feature, Not a Bug: Secure and Auditable State Rollback for Confidential Cloud Applications

Quinn Burke , Anjo Vahldiek-Oberwagner , Michael Swift , Patrick McDaniel This is my paper

Pith reviewed 2026-05-17 21:57 UTC · model grok-4.3

classification 💻 cs.CR
keywords rollback protectionconfidential computingreference monitortamper-evident logstate continuitysecure rollbackcloud securityauditability
0
0 comments X

The pith

Rebound lets cloud applications roll back to prior states when authorized by policy while still blocking malicious replays through a reference monitor and tamper-evident logs.

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

The paper introduces Rebound as a framework that keeps protection against replay and rollback attacks on confidential cloud applications but adds support for legitimate rollbacks used in recovery. Prior systems enforced only forward state changes and therefore blocked useful operations such as restoring a corrupted configuration or rolling back to a known-good binary. Rebound inserts a reference monitor between the application and untrusted storage to check authorization policies, make transitions atomic, and write an auditable log. The authors demonstrate the approach on a GitLab CI deployment workflow and report low overhead while preserving the security guarantees of earlier state-continuity schemes.

Core claim

Rebound preserves rollback protection while enabling policy-authorized legitimate rollbacks of application binaries, configuration, and data through a reference monitor that mediates state transitions, enforces authorization policy, guarantees atomicity, and emits a tamper-evident log that provides transparency to applications and auditors.

What carries the argument

A reference monitor that mediates state transitions between an application and untrusted storage, checks authorization policies, ensures atomic updates or rollbacks, and produces a tamper-evident log.

If this is right

  • Applications gain the ability to recover from corruption or misconfiguration without opening the door to replay attacks.
  • Auditors obtain a verifiable record of every state transition including authorized rollbacks.
  • Secure deployment pipelines can safely version binaries, configurations, and raw data under explicit policy control.
  • The added mechanisms impose only low end-to-end overhead on typical cloud workloads.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same monitor-plus-log pattern could be applied to other forms of state management that currently forbid all rollbacks.
  • Policy languages for authorizing rollbacks become a new point of attack surface that requires separate verification.
  • Integration with hardware attestation could strengthen the assumption that the monitor itself has not been subverted.

Load-bearing premise

Authorization policies can be written correctly and the reference monitor itself stays trustworthy and uncompromised when it sits between the application and storage.

What would settle it

Demonstrate an attacker who can force an unauthorized rollback of application state or tamper with the log without the reference monitor detecting or logging the violation.

Figures

Figures reproduced from arXiv: 2511.13641 by Anjo Vahldiek-Oberwagner, Michael Swift, Patrick McDaniel, Quinn Burke.

Figure 1
Figure 1. Figure 1: Confidential applications run inside TEEs on untrusted cloud [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Conventional state continuity frameworks prevent rollback attacks [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: REBOUND high-level system architecture. and seals them in a single authoritative order. Clients and auditors attest and trust this reference monitor and only perform verifications against its sealed state [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: REBOUND uses a tailored authenticated dictionary to accumulate prior object versions and policy provenance under the authoritative root R. point—given any sealed state at counter c, verifiers can cryptographically trace forward through version histories in V, resolve snapshot membership via S, and cross-check actions against audit records in L, all anchored to R. As the system evolves and each new operatio… view at source ↗
Figure 4
Figure 4. Figure 4: In REBOUND, rollback is represented and executed as a forward state transition that creates a new state and records lineage metadata (i.e., origin pointer) that can be used by auditors to reconstruct lineage. 4.3. Co-Sealing History and Policy Decisions With the capability to accumulate history and policy decisions in append-only structures, the next question is the semantics of verification. Consider what… view at source ↗
Figure 6
Figure 6. Figure 6: End-to-end latency for build/deploy and rollback jobs. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: End-to-end latency for maintenance jobs. Snapshot creation, [PITH_FULL_IMAGE:figures/full_fig_p011_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Query latency vs. history length. OVM queries scale logarithmically [PITH_FULL_IMAGE:figures/full_fig_p012_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Bounded history accumulation and storage costs with pruning. [PITH_FULL_IMAGE:figures/full_fig_p012_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: State update protocol: appends to V, optionally S, and L, then co-seals under R′ . Rollback Protocol. Input: current authoritative state (R, c); rollback request specifying either snapshot id s or explicit target set T = {(Oi, ki)} where ki denotes historical counter values, plus justification. Output: new authoritative state (R ′ , c′ , σ′ ) and authenticated log records. Note: systems typically operate … view at source ↗
Figure 13
Figure 13. Figure 13: Pruning protocol: verifies version existence in [PITH_FULL_IMAGE:figures/full_fig_p017_13.png] view at source ↗
read the original abstract

Replay and rollback attacks threaten cloud application integrity by reintroducing authentic yet stale data through an untrusted storage interface to compromise application decision-making. Prior security frameworks mitigate these attacks by enforcing forward-only state transitions (state continuity) with hardware-backed mechanisms, but they categorically treat all rollback as malicious and thus preclude legitimate rollbacks used for operational recovery from corruption or misconfiguration. We present Rebound, a general-purpose security framework that preserves rollback protection while enabling policy-authorized legitimate rollbacks of application binaries, configuration, and data. Key to Rebound is a reference monitor that mediates state transitions, enforces authorization policy, guarantees atomicity of state updates and rollbacks, and emits a tamper-evident log that provides transparency to applications and auditors. We analyze Rebound's security properties and show through an application case study -- with software deployment workflows in GitLab CI -- that it enables robust control over binary, configuration, and raw data versioning with low end-to-end overhead.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents Rebound, a general-purpose security framework for confidential cloud applications that preserves protection against replay and rollback attacks while enabling policy-authorized legitimate rollbacks of binaries, configuration, and data. The core mechanism is a reference monitor that mediates all state transitions, enforces authorization policies, guarantees atomicity of updates and rollbacks, and emits a tamper-evident log for transparency and auditing. The work includes an analysis of security properties and demonstrates the approach via a GitLab CI case study on software deployment workflows, claiming low end-to-end overhead.

Significance. If the security properties and implementation details hold, this work would be significant for confidential computing. It fills a practical gap left by prior hardware-backed state continuity systems that disallow all rollbacks, thereby supporting operational recovery from corruption or misconfiguration without weakening integrity guarantees. The emphasis on auditable, policy-driven rollbacks and tamper-evident logging could aid compliance and debugging in cloud environments, and the GitLab CI case study suggests direct relevance to real deployment pipelines.

major comments (2)
  1. [§4 (Security Analysis)] §4 (Security Analysis): The central claim that Rebound preserves rollback protection for malicious cases while permitting authorized ones rests on the reference monitor remaining uncompromised and able to mediate all transitions with untrusted storage. The manuscript does not detail hardware-rooted isolation, attestation, or anti-rollback protections specifically for the monitor itself; without these, an adversary controlling storage could potentially inject unauthorized transitions while maintaining log consistency, directly undermining the distinction between legitimate and malicious rollbacks.
  2. [§5 (Evaluation)] §5 (Evaluation): The GitLab CI case study is presented as evidence of robust versioning control with low overhead, yet the abstract and summary provide no quantitative metrics such as latency, throughput deltas, or baseline comparisons. This absence makes it difficult to evaluate whether the atomicity and logging mechanisms impose acceptable costs in practice, which is load-bearing for the practicality claim.
minor comments (2)
  1. [Abstract] Abstract: The threat model is not summarized (e.g., what capabilities the untrusted storage provider is assumed to have), which would clarify the scope of the security analysis for readers.
  2. The manuscript would benefit from an explicit statement of the authorization policy language or examples of policies used in the GitLab CI case study to make the mediation mechanism more concrete.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive comments, which highlight important areas for clarification in our presentation of Rebound. We address each major comment below and indicate the revisions we will make to the manuscript.

read point-by-point responses

  1. Referee: [§4 (Security Analysis)] §4 (Security Analysis): The central claim that Rebound preserves rollback protection for malicious cases while permitting authorized ones rests on the reference monitor remaining uncompromised and able to mediate all transitions with untrusted storage. The manuscript does not detail hardware-rooted isolation, attestation, or anti-rollback protections specifically for the monitor itself; without these, an adversary controlling storage could potentially inject unauthorized transitions while maintaining log consistency, directly undermining the distinction between legitimate and malicious rollbacks.

    Authors: We agree that explicit details on the reference monitor's own protections are necessary to fully substantiate the security claims. The revised manuscript will expand the security analysis in §4 to describe the reference monitor's deployment inside a hardware-protected TEE (consistent with the confidential computing setting of the paper), including use of remote attestation to verify its integrity at initialization and the TEE's built-in anti-rollback mechanisms to protect the monitor's internal state. These additions will clarify why an adversary with control over storage cannot forge or inject unauthorized transitions without detection in the tamper-evident log or violation of atomicity guarantees. revision: yes

  2. Referee: [§5 (Evaluation)] §5 (Evaluation): The GitLab CI case study is presented as evidence of robust versioning control with low overhead, yet the abstract and summary provide no quantitative metrics such as latency, throughput deltas, or baseline comparisons. This absence makes it difficult to evaluate whether the atomicity and logging mechanisms impose acceptable costs in practice, which is load-bearing for the practicality claim.

    Authors: The evaluation section contains the requested quantitative results, but we acknowledge that the abstract and high-level summary omit specific numbers. In the revised manuscript we will update the abstract to report key measured values from the GitLab CI case study, including end-to-end latency overhead for state transitions and rollbacks (relative to an unprotected baseline) and throughput impact under the evaluated workload. This will make the practicality claim easier to assess without requiring the reader to reach §5. revision: yes

Circularity Check

0 steps flagged

No significant circularity in Rebound's framework derivation

full rationale

The paper introduces Rebound as a reference monitor mediating state transitions with authorization policies, atomicity guarantees, and tamper-evident logging, built on standard hardware-backed continuity mechanisms. No equations, fitted parameters, or self-referential definitions appear; security properties follow directly from the described design choices rather than reducing to inputs by construction. The framework is self-contained against external benchmarks such as TEE isolation and auditable logs, with no load-bearing self-citations or ansatz smuggling identified in the provided abstract and description.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The design rests on standard assumptions from confidential computing literature about the trustworthiness of hardware roots of trust and the ability to define correct authorization policies outside the monitor.

axioms (2)
  • domain assumption Hardware-backed mechanisms exist that can enforce forward-only state transitions when desired.
    Invoked when describing how prior frameworks achieve state continuity and how Rebound selectively relaxes it.
  • domain assumption Authorization policies can be specified correctly by administrators and will not be bypassed by the untrusted storage layer.
    Central to the claim that only legitimate rollbacks are permitted.

pith-pipeline@v0.9.0 · 5478 in / 1366 out tokens · 43668 ms · 2026-05-17T21:57:36.408857+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

85 extracted references · 85 canonical work pages · 1 internal anchor

  1. [1]

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

    C. che Tsai, D. E. Porter, and M. Vij, “Graphene-SGX: A practical library OS for unmodified applications on SGX,” in2017 USENIX Annual Technical Conference (USENIX ATC 17). Santa Clara, CA: USENIX Association, Jul. 2017, pp. 645–658. [Online]. Available: https://www.usenix.org/conference/atc17/technical-sessions/ presentation/tsai

    work page 2017

  2. [2]

    Trustworthy confidential virtual machines for the masses,

    A. Galanou, K. Bindlish, L. Preibsch, Y .-A. Pignolet, C. Fetzer, and R. Kapitza, “Trustworthy confidential virtual machines for the masses,” inProceedings of the 24th International Middleware Conference, 2023, pp. 316–328

    work page 2023

  3. [3]

    Practical {Data-Only} attack generation,

    B. Johannesmeyer, A. Slowinska, H. Bos, and C. Giuffrida, “Practical {Data-Only} attack generation,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 1401–1418

    work page 2024

  4. [4]

    Data-only attacks are easier than you think,

    O. Hoven, D. Genkin, D. Evtyushkin, Q. Ge, and Y . Zhang, “Data-only attacks are easier than you think,”login; USENIX, 2019. [Online]. Available: https://www.usenix.org/publications/loginonline/ data-only-attacks-are-easier-you-think

    work page 2019

  5. [5]

    Memoir: Practical state continuity for protected modules,

    B. Parno, J. R. Lorch, J. R. Douceur, J. Mickens, and J. M. McCune, “Memoir: Practical state continuity for protected modules,” in2011 IEEE Symposium on Security and Privacy. IEEE, 2011, pp. 379–394

    work page 2011

  6. [6]

    Nimble: Rollback protection for confidential cloud services,

    S. Angel, A. Basu, W. Cui, T. Jaeger, S. Lau, S. Setty, and S. Singana- malla, “Nimble: Rollback protection for confidential cloud services,” in17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23), 2023, pp. 193–208

    work page 2023

  7. [7]

    {ROTE}: Rollback protection for trusted execution,

    S. Matetic, M. Ahmed, K. Kostiainen, A. Dhar, D. Sommer, A. Gervais, A. Juels, and S. Capkun, “ {ROTE}: Rollback protection for trusted execution,” in26th USENIX Security Symposium (USENIX Security 17), 2017, pp. 1289–1306

    work page 2017

  8. [8]

    Ariadne: A minimal approach to state continuity,

    R. Strackx and F. Piessens, “Ariadne: A minimal approach to state continuity,” in25th USENIX Security Symposium (USENIX Security 16), 2016, pp. 875–892

    work page 2016

  9. [9]

    Devops project management: Aligning development and operations teams,

    R. R. Alluri, T. A. Venkat, D. K. D. Pal, S. M. Yellepeddi, and S. Thota, “Devops project management: Aligning development and operations teams,”Journal of Science & Technology, vol. 1, no. 1, pp. 464–87, 2020

    work page 2020

  10. [10]

    Ci/cd pipelines evolution and restructuring: A qualitative and quantitative study,

    F. Zampetti, S. Geremia, G. Bavota, and M. Di Penta, “Ci/cd pipelines evolution and restructuring: A qualitative and quantitative study,” in 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2021, pp. 471–482

    work page 2021

  11. [11]

    Foundational devops patterns,

    P. Marques and F. F. Correia, “Foundational devops patterns,”arXiv preprint arXiv:2302.01053, 2023

    work page arXiv 2023

  12. [12]

    Ccxtrust: Confidential computing platform based on tee and tpm collaborative trust,

    K. Shang, J. Lin, Y . Qin, M. Shen, H. Ma, W. Feng, and D. Feng, “Ccxtrust: Confidential computing platform based on tee and tpm collaborative trust,”arXiv preprint arXiv:2412.03842, 2024

    work page arXiv 2024

  13. [13]

    T. Group. (2025) Monotonic counter objects in thales protectserver hsm. Accessed: 2025-11-10. [Online]. Available: https://thalesdocs.com/gphsm/ptk/protectserver3/docs/ps_ptk_docs/ ptkc_programming/object_classes/monotonic_count_obj/index.html

    work page 2025

  14. [14]

    Adam-cs: Advanced asynchronous monotonic counter ser- vice,

    A. Martin, C. Lian, F. Gregor, R. Krahn, V . Schiavoni, P. Felber, and C. Fetzer, “Adam-cs: Advanced asynchronous monotonic counter ser- vice,” inProceedings of the International Conference on Dependable Systems and Networks, 2021

    work page 2021

  15. [15]

    Vmcaas-virtual monotonic counters as a service,

    G. Fernandez, J. Wenzel, and C. Fetzer, “Vmcaas-virtual monotonic counters as a service,” inProceedings of the International Conference on Utility and Cloud Computing, 2024

    work page 2024

  16. [16]

    Both, “Btrfs,” inUsing and Administering Linux: Volume 2: Zero to SysAdmin: Advanced Topics

    D. Both, “Btrfs,” inUsing and Administering Linux: Volume 2: Zero to SysAdmin: Advanced Topics. Springer, 2023, pp. 481–505

    work page 2023

  17. [17]

    End-to-end data integrity for file systems: A ZFS case study,

    Y . Zhang, A. Rajimwale, A. C. Arpaci-Dusseau, and R. H. Arpaci-Dusseau, “End-to-end data integrity for file systems: A ZFS case study,” in8th USENIX Conference on File and Storage Technologies (FAST 10). San Jose, CA: USENIX Association, Feb

    work page

  18. [18]

    Available: https://www.usenix.org/conference/fast-10/ end-end-data-integrity-file-systems-zfs-case-study

    [Online]. Available: https://www.usenix.org/conference/fast-10/ end-end-data-integrity-file-systems-zfs-case-study

    work page

  19. [19]

    Trap-array: A disk array architecture providing timely recovery to any point-in-time,

    Q. Yang, W. Xiao, and J. Ren, “Trap-array: A disk array architecture providing timely recovery to any point-in-time,”ACM SIGARCH Computer Architecture News, vol. 34, no. 2, pp. 289–301, 2006

    work page 2006

  20. [20]

    Checkpointing for peta-scale systems: A look into the future of practical rollback-recovery,

    E. N. Elnozahy and J. S. Plank, “Checkpointing for peta-scale systems: A look into the future of practical rollback-recovery,”IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 2, pp. 97–108, 2004

    work page 2004

  21. [21]

    Failures and fixes: A study of software system incident response,

    J. Sillito and E. Kutomi, “Failures and fixes: A study of software system incident response,” in2020 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2020, pp. 185–195

    work page 2020

  22. [22]

    Botched releases: Do we need to roll back? empirical study on a commercial web app,

    N. Kerzazi and B. Adams, “Botched releases: Do we need to roll back? empirical study on a commercial web app,” in2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), vol. 1. IEEE, 2016, pp. 574–583

    work page 2016

  23. [23]

    Persistent authenticated dictionaries and their applications,

    A. Anagnostopoulos, M. T. Goodrich, and R. Tamassia, “Persistent authenticated dictionaries and their applications,” inInternational Conference on Information Security. Springer, 2001, pp. 379–393

    work page 2001

  24. [24]

    Amazon dynamodb: a seamlessly scalable non- relational database service,

    S. Sivasubramanian, “Amazon dynamodb: a seamlessly scalable non- relational database service,” inProceedings of the 2012 ACM SIGMOD International Conference on Management of Data, 2012, pp. 729–730

    work page 2012

  25. [25]

    O’Reilly Media, Inc

    E. Hewitt,Cassandra: the definitive guide. " O’Reilly Media, Inc.", 2010

    work page 2010

  26. [26]

    SPEICHER: Securing LSM-based Key-Value stores using shielded execution,

    M. Bailleu, J. Thalheim, P. Bhatotia, C. Fetzer, M. Honda, and K. Vaswani, “SPEICHER: Securing LSM-based Key-Value stores using shielded execution,” in17th USENIX Conference on File and Storage Technologies (FAST 19). Boston, MA: USENIX Association, Feb. 2019, pp. 173–190. [Online]. Available: https://www.usenix.org/conference/fast19/presentation/bailleu

    work page 2019

  27. [27]

    Narrator: Secure and practical state continuity for trusted execution in the cloud,

    J. Niu, W. Peng, X. Zhang, and Y . Zhang, “Narrator: Secure and practical state continuity for trusted execution in the cloud,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 2385–2399

    work page 2022

  28. [28]

    T. Dev. (2025) Tessera. Transparency Dev. [Online]. Available: https://github.com/transparency-dev/tessera

    work page 2025

  29. [29]

    Verifiable data structures,

    A. Eijdenberg, B. Laurie, and A. Cutter, “Verifiable data structures,” Google Research, Tech. Rep, 2015

    work page 2015

  30. [30]

    Microservices: yesterday, today, and tomorrow

    N. Dragoni, S. Giallorenzo, A. Lluch-Lafuente, M. Mazzara, F. Montesi, R. Mustafin, and L. Safina, “Microservices: yesterday, today, and tomorrow,”CoRR, vol. abs/1606.04036, 2016, _eprint: 1606.04036. [Online]. Available: http://arxiv.org/abs/1606.04036

    work page internal anchor Pith review Pith/arXiv arXiv 2016

  31. [31]

    Microservices: Architecting for Continuous Delivery abnd DevOps,

    L. Chen, “Microservices: Architecting for Continuous Delivery abnd DevOps,” inProceedings of the IEEE International Conference on Software Architecture (ICSA), 2018

    work page 2018

  32. [32]

    in-toto: Providing farm-to-table guarantees for bits and bytes,

    S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos, “in-toto: Providing farm-to-table guarantees for bits and bytes,” in28th USENIX Security Symposium (USENIX Security 19), 2019, pp. 1393–1410

    work page 2019

  33. [33]

    Performance overheads of confidential virtual machines,

    M. Yan and K. Gopalan, “Performance overheads of confidential virtual machines,” in2023 31st International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS). IEEE, 2023, pp. 1–8

    work page 2023

  34. [34]

    Sigstore: Software signing for everybody,

    Z. Newman, J. S. Meyers, and S. Torres-Arias, “Sigstore: Software signing for everybody,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 2353–2367. 14

    work page 2022

  35. [35]

    Efficient Storage Integrity in Adversarial Settings,

    Q. Burke, R. Sheatsley, Y . Beugin, E. Pauley, O. Hines, M. Swift, and P. McDaniel, “Efficient Storage Integrity in Adversarial Settings,” in 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025, pp. 3145–3160

    work page 2025

  36. [36]

    A certified digital signature,

    R. C. Merkle, “A certified digital signature,” inConference on the Theory and Application of Cryptology. Springer, 1989, pp. 218–238

    work page 1989

  37. [37]

    Veritasdb: High throughput key- value store with integrity,

    R. Sinha and M. Christodorescu, “Veritasdb: High throughput key- value store with integrity,”Cryptology ePrint Archive, 2018

    work page 2018

  38. [38]

    Fastver: Making data integrity a commodity,

    A. Arasu, B. Chandramouli, J. Gehrke, E. Ghosh, D. Kossmann, J. Protzenko, R. Ramamurthy, T. Ramananandro, A. Rastogi, S. Setty et al., “Fastver: Making data integrity a commodity,” inProceedings of the 2021 International Conference on Management of Data, 2021, pp. 89–101

    work page 2021

  39. [39]

    Authenticated data structures,

    R. Tamassia, “Authenticated data structures,” inAlgorithms-ESA 2003: 11th Annual European Symposium, Budapest, Hungary, September 16-19, 2003. Proceedings 11. Springer, 2003, pp. 2–5

    work page 2003

  40. [40]

    Dynamic provable data possession,

    C. C. Erway, A. Küpçü, C. Papamanthou, and R. Tamassia, “Dynamic provable data possession,”ACM Transactions on Information and System Security (TISSEC), vol. 17, no. 4, pp. 1–29, 2015

    work page 2015

  41. [41]

    Certificate revocation and certificate update,

    M. Naor and K. Nissim, “Certificate revocation and certificate update,” IEEE Journal on selected areas in communications, vol. 18, no. 4, pp. 561–570, 2000

    work page 2000

  42. [42]

    Authenticated data structures, generically,

    A. Miller, M. Hicks, J. Katz, and E. Shi, “Authenticated data structures, generically,”ACM SIGPLAN Notices, vol. 49, no. 1, pp. 411–423, 2014

    work page 2014

  43. [43]

    Innovative instructions and software model for isolated execution,

    F. McKeen, I. Alexandrovich, A. Berenzon, C. V . Rozas, H. Shafi, V . Shanbhogue, and U. R. Savagaonkar, “Innovative instructions and software model for isolated execution,” in Proceedings of the 2nd International Workshop on Hardware and Architectural Support for Security and Privacy - HASP ’13. Tel-Aviv, Israel: ACM Press, 2013. [Online]. Available: htt...

    work page arXiv 2013

  44. [44]

    Amd sev-snp in amazon ec2,

    A. W. Services, “Amd sev-snp in amazon ec2,” https://docs.aws. amazon.com/AWSEC2/latest/UserGuide/sev-snp.html, 2024, accessed: 2024-08-19

    work page 2024

  45. [45]

    Shielding applications from an untrusted cloud with haven,

    A. Baumann, M. Peinado, and G. Hunt, “Shielding applications from an untrusted cloud with haven,”ACM Transactions on Computer Systems (TOCS), vol. 33, no. 3, pp. 1–26, 2015

    work page 2015

  46. [46]

    Trusted Execution Environment: What It is, and What It is Not,

    M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted Execution Environment: What It is, and What It is Not,” in2015 IEEE Trustcom/BigDataSE/ISPA. Helsinki, Finland: IEEE, Aug. 2015, pp. 57–64. [Online]. Available: http://ieeexplore.ieee.org/document/ 7345265/

    work page 2015

  47. [47]

    TrustZone Explained: Architectural Features and Use Cases,

    B. Ngabonziza, D. Martin, A. Bailey, H. Cho, and S. Martin, “TrustZone Explained: Architectural Features and Use Cases,” in2016 IEEE 2nd International Conference on Collaboration and Internet Computing (CIC). Pittsburgh, PA, USA: IEEE, Nov. 2016, pp. 445–

    work page 2016

  48. [48]

    Available: http://ieeexplore.ieee.org/document/7809736/

    [Online]. Available: http://ieeexplore.ieee.org/document/7809736/

    work page arXiv

  49. [49]

    Sok: Benchmarking flaws in systems security,

    E. van der Kouwe, G. Heiser, D. Andriesse, H. Bos, and C. Giuffrida, “Sok: Benchmarking flaws in systems security,” in2019 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2019, pp. 310–325

    work page 2019

  50. [50]

    Intel sgx explained,

    V . Costan and S. Devadas, “Intel sgx explained,”IACR Cryptol. ePrint Arch., vol. 2016, p. 86, 2016

    work page 2016

  51. [51]

    Authenticated dictionaries: Real- world costs and trade-offs,

    S. A. Crosby and D. S. Wallach, “Authenticated dictionaries: Real- world costs and trade-offs,”ACM Transactions on Information and System Security (TISSEC), vol. 14, no. 2, pp. 1–30, 2011

    work page 2011

  52. [52]

    Auditing file system permissions using association rule mining,

    S. Parkinson, V . Somaraki, and R. Ward, “Auditing file system permissions using association rule mining,”Expert Systems with Applications, vol. 55, pp. 274–283, 2016

    work page 2016

  53. [53]

    Custos: Practical tamper-evident auditing of operating systems using trusted execution,

    R. Paccagnella, P. Datta, W. U. Hassan, A. Bates, C. Fletcher, A. Miller, and D. Tian, “Custos: Practical tamper-evident auditing of operating systems using trusted execution,” inNetwork and distributed system security symposium, 2020

    work page 2020

  54. [54]

    Hardlog: Practical tamper-proof system auditing using a novel audit device,

    A. Ahmad, S. Lee, and M. Peinado, “Hardlog: Practical tamper-proof system auditing using a novel audit device,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 1791–1807

    work page 2022

  55. [55]

    Sok: History is a vast early warning system: Auditing the provenance of system intrusions,

    M. A. Inam, Y . Chen, A. Goyal, J. Liu, J. Mink, N. Michael, S. Gaur, A. Bates, and W. U. Hassan, “Sok: History is a vast early warning system: Auditing the provenance of system intrusions,” inProceedings of the IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 2620–2638

    work page 2023

  56. [56]

    Omegalog: High-fidelity attack investigation via transparent multi-layer log analysis,

    W. U. Hassan, M. A. Noureddine, P. Datta, and A. Bates, “Omegalog: High-fidelity attack investigation via transparent multi-layer log analysis,” inProceedings of the Network and Distributed System Security Symposium, 2020

    work page 2020

  57. [57]

    Runtime analysis of whole-system provenance,

    T. Pasquier, X. Han, T. Moyer, A. Bates, O. Hermant, D. Eyers, J. Ba- con, and M. Seltzer, “Runtime analysis of whole-system provenance,” inProceedings of the ACM SIGSAC conference on Computer and Communications Security, 2018, pp. 1601–1616

    work page 2018

  58. [58]

    Secure provenance using an authenticated data structure approach,

    F. Jamil, A. Khan, A. Anjum, M. Ahmed, F. Jabeen, and N. Javaid, “Secure provenance using an authenticated data structure approach,” computers & security, vol. 73, pp. 34–56, 2018

    work page 2018

  59. [59]

    Threat detection and investigation with system-level provenance graphs: A survey,

    Z. Li, Q. A. Chen, R. Yang, Y . Chen, and W. Ruan, “Threat detection and investigation with system-level provenance graphs: A survey,” Computers & Security, vol. 106, p. 102282, 2021

    work page 2021

  60. [60]

    Bonsai: Balanced lineage authentication,

    A. Gehani and U. Lindqvist, “Bonsai: Balanced lineage authentication,” inTwenty-Third Annual Computer Security Applications Conference (ACSAC 2007). IEEE, 2007, pp. 363–373

    work page 2007

  61. [61]

    Git: Fast version control system,

    L. Torvalds and J. Hamano, “Git: Fast version control system,”URL http://git-scm. com, p. 19, 2010

    work page 2010

  62. [62]

    Recovery techniques for database systems,

    J. S. Verhofstad, “Recovery techniques for database systems,”ACM Computing Surveys (CSUR), vol. 10, no. 2, pp. 167–195, 1978. Appendix REBOUNDProtocols Crash Recovery & Double-Increment Discipline The double-increment discipline prevents a specific class of hardware-based crash attacks. Consider an attacker who can trigger crashes (e.g., via power faults ...

    work page 1978

  63. [63]

    Intent Declaration.Generate a fresh transaction identifier txid; append intent record to audit log L containing prior root R, affected object identifiers, and (optionally) snapshot tagtwith the counter-indexed versions it would bind

    work page

  64. [64]

    Abort on any failure

    Policy & Integrity Validation.Verify proposer authoriza- tion, required approvals, time constraints, object depen- dency/consistency rules, and integrity of proposed bytes (hash, format, signature checks). Abort on any failure

    work page

  65. [65]

    The version identifier is the next counter valuec ′ =c+ 1

    Per-Object Digest Preparation.For each Oi ∈∆ , compute new content digest hnew i . The version identifier is the next counter valuec ′ =c+ 1

    work page

  66. [66]

    Record the prior head value as the origin pointer in the version metadata, establishing the predecessor relation for lineage reconstruction

    Version Catalog Extension.Append new entries to V mapping each (Oi, c′) to hnew i and update the head pointer for each Oi to c′. Record the prior head value as the origin pointer in the version metadata, establishing the predecessor relation for lineage reconstruction

    work page

  67. [67]

    Optional Snapshot Registration.If requested, append entry to S binding tag t to the counter-indexed versions (object-counter pairs)

    work page

  68. [68]

    Completion Logging.Append completion record to L linking txid, prior root R, and the affected objects with their counter-indexed versions

    work page

  69. [69]

    Sealing.Compute roots HV, HS, HL of the three PADs, aggregate them into new authoritative root R′, and obtain sealσ ′ =Seal(R ′, c′)wherec ′ =c+ 1

    work page

  70. [70]

    Figure 11

    Publication.Durably persist (R′, c′, σ′), then advance the hardware monotonic counter from c to c′ to finalize (R, c)←(R ′, c′), makingR ′ authoritative. Figure 11. State update protocol: appends to V, optionally S, and L, then co-seals underR ′. Rollback Protocol.Input:current authoritative state (R, c); rollback request specifying either snapshot id s o...

    work page

  71. [71]

    Intent Declaration.Generate a fresh transaction identifier txid; append intent record to L with prior root R, mode (snapshot-based or selective), snapshot id or explicit target set, current heads of affected objects, actor, and justifica- tion

    work page

  72. [72]

    Abort on failure

    Eligibility Validation.Check approvals and time windows; for each target (Oi, ki) verify inclusion in V under R and absence of de-authorization tombstones; if snapshot-based, verify snapshot binding inSunderR. Abort on failure

    work page

  73. [73]

    Historical Version Authentication.For each (Oi, ki), verify inclusion proof in V under R, retrieving content digesth ki i from the entry at counterk i

    work page

  74. [74]

    Record ki as the origin pointer in the version metadata to link the new version to its historical source, enabling rollback detection in lineage reconstruction

    Version Catalog Extension.For each affected object append entry to V mapping (Oi, c′) to hki i (reusing the historical digest) where c′ =c+ 1 is the next counter value; update head pointer for Oi to c′. Record ki as the origin pointer in the version metadata to link the new version to its historical source, enabling rollback detection in lineage reconstru...

    work page

  75. [75]

    Completion Logging.Append completion record to L linking txid, the intent, and the affected objects with their new counter-indexed versions

    work page

  76. [76]

    Sealing.Compute roots HV, HS, HL, aggregate into R′, and computeσ ′ =Seal(R ′, c′)wherec ′ =c+ 1

    work page

  77. [77]

    Figure 12

    Publication.Durably store (R′, c′, σ′), then advance the hardware monotonic counter from c to c′ to finalize (R, c)←(R ′, c′), makingR ′ authoritative. Figure 12. Rollback protocol: verifies eligibility in V and S under R, creates new version entries reusing historical digests, logs to L, and co-seals under R′. 16 Pruning Protocol.Input:current authoritat...

    work page

  78. [78]

    Intent Declaration.Generate a fresh transaction identifier txid; append intent record to L with prior root R, mode (snapshot-based or selective), snapshot tag or explicit candidate set P (object identifiers with counter values), policy context, actor, and justification

    work page

  79. [79]

    LetP={(O i, ki)}be the resolved retire set

    Target Resolution.If snapshot-based, resolve tag t to version set via S under R; if selective, use provided set P. LetP={(O i, ki)}be the resolved retire set

    work page

  80. [80]

    Abort on failure

    Eligibility Validation.Enforce retention and revocation policies; for each (Oi, ki)∈P verify inclusion in V under R and that no de-authorization tombstone exists for it. Abort on failure

    work page

Showing first 80 references.