Karim Eldefrawy

Cryptography, Cybersecurity, Privacy

Co-founder and CTO at Confidencial.io
2017-2021: SRI
2011-2016: HRL Laboratories
2006-2010: PhD@UC Irvine

Scientific curiosity

Scientific knowledge map · Paper #23

An Architecture for a Resilient Cloud Computing Infrastructure

Joshua Baron, Karim Eldefrawy, Aleksey Nogin, and Rafail Ostrovsky

2013 · IEEE International Conference on Technologies for Homeland Security (HST)

  • Applied
  • protocol

What does the paper try to establish?

Can a cloud continue supervising and executing distributed jobs despite an ongoing stream of node compromises, provided compromise occurs below a bounded rate and nodes can periodically return to a pristine state?

What is the proposed answer?

The source abstract proposes a Control Operations Plane that separates trusted task supervision and end-user communication from user jobs, uses robust cryptographic protocols, and combines software refresh with hardware-assisted regeneration; the paper body was not obtained for this audit, so the precise model, proof, protocol, and evaluation remain unverified here.

Abstract

This paper proposes an architecture for a resilient cloud computing infrastructure that provably maintains cloud functionality against persistent successful corruptions of cloud nodes. The architecture is composed of a self-healing software mechanism for the entire cloud, as well as hardware-assisted regeneration of compromised (or faulty) nodes from a pristine state. Such an architecture aims to secure critical distributed cloud computations well beyond the current state of the art by tolerating, in a seamless fashion, a continuous rate of successful corruptions up to certain corruption rate limit, e.g., 30% of all cloud nodes may be corrupted within a tunable window of time. The proposed architecture achieves these properties based on a principled separation of distributed task supervision from the computation of user-defined jobs. The task supervision and enduser communication are performed by a new software mechanism called the Control Operations Plane (COP), which builds a trustworthy and resilient, self-healing cloud computing infrastructure out of the underlying untrustworthy and faulty hosts. The COP leverages provably-secure cryptographic protocols that are efficient and robust in the presence of many corrupted participants — such a cloud regularly and unobtrusively refreshes itself by restoring COP nodes from a pristine state at regular intervals.

Provenance: Transcribed from the public author-uploaded full text; only typography, discretionary hyphenation, and line-break artifacts were normalized. Source wording such as 'enduser' is retained. Local file fixity has not been recorded.

Six dimensions, kept separate

The chart summarizes documented evidence and process. It is not a correctness probability, confidence score, or ranking, and no composite score is calculated.

The visual spider chart requires JavaScript. The complete values and rationales follow in text.

LowMediumHighN/A = not assessed

A smaller value means less documented support for that dimension, not that the paper is false or unimportant.

Epistemic evidence Low

A complete source abstract identifies the architecture and intended guarantee, but the model, protocol, proof, and evaluation body were not obtained or audited.

Complete author-uploaded source abstract
Auditability High

A public author-uploaded full-text route exists, satisfying the site's author-copy rule, but this audit could not retrieve and locally fix the body; the map therefore remains abstract-grounded.

Complete author-uploaded source abstract
Production provenance Medium

Named authorship, an author-uploaded record, and an IEEE publication record establish baseline provenance; roles, revisions, and artifact lineage are unknown.

Complete author-uploaded source abstract Official IEEE publication record
External scrutiny Medium

The work has an IEEE conference publication record, but review materials and independent validation were not inspected.

Official IEEE publication record
Reception Low

OpenAlex reports 2 located citations as of 2026-07-11. The count is index-specific and may omit versions or citations.

Dated OpenAlex citation snapshot
Contribution significance Medium

The abstract presents a distinctive proactive cloud-control architecture, but novelty priority, theorem strength, and downstream impact were not body-audited.

Complete author-uploaded source abstract

Assessment: Ai draft author review pending · 2026-07-11 · rubric 0.2. These dimensions describe documented support and process, not truth, correctness, or a universal ranking. No composite score is calculated.

Hierarchical knowledge map

Collapse a branch for a top-level reading, or follow its source links and child nodes to audit the evidence and boundaries underneath it.

paper

An Architecture for a Resilient Cloud Computing Infrastructure

An abstract-grounded architecture for a self-healing cloud control layer that combines cryptographic protocols with periodic regeneration of compromised nodes.

Complete author-uploaded source abstract
  1. question

    Research question

    research question from abstract

    How can critical cloud functionality survive persistent successful node corruptions rather than only a fixed set of failures?

    Complete author-uploaded source abstract
  2. contribution

    Central answer

    source abstract asserted

    Separate supervision from user computation in a Control Operations Plane and periodically restore its nodes from pristine state while robust cryptographic protocols maintain distributed control.

    Complete author-uploaded source abstract
  3. scope Abstract-level model abstract level

    The abstract describes untrustworthy cloud hosts, continuous successful corruptions below a rate limit, tunable recovery windows, and hardware-assisted restoration.

    Complete author-uploaded source abstract
    1. threat model

      Persistent mobile compromise

      incompletely specified

      The motivating adversary can repeatedly compromise nodes; the abstract gives 30% within a tunable window as an example, not enough detail here to reconstruct exact quantifiers, scheduling power, or synchrony assumptions.

      Complete author-uploaded source abstract
  4. method Control Operations Plane source abstract asserted

    COP handles distributed task supervision and end-user communication separately from user-defined jobs, creating a narrow control substrate over faulty hosts.

    Complete author-uploaded source abstract
    1. component

      Software refresh plus hardware regeneration

      source abstract asserted

      The architecture combines cloud-wide self-healing software with regular hardware-assisted restoration of compromised or faulty COP nodes from a pristine state.

      Complete author-uploaded source abstract
  5. claim group

    Abstract-level claims

    abstract only

    The abstract claims maintained cloud functionality below a corruption-rate bound and attributes it to COP, robust cryptographic protocols, and periodic regeneration.

    Complete author-uploaded source abstract
  6. limitation group

    Unverified boundaries

    material source gap

    The map cannot certify the exact corruption/recovery schedule, threshold, liveness model, trusted hardware state, protocol instantiation, proof theorem, performance, or deployment evidence without the manuscript body.

    Complete author-uploaded source abstract
  7. scrutiny

    External scrutiny

    publication recorded

    The work was published at IEEE HST 2013; review reports, proof checking, reproductions, and later operational evaluations were not audited.

    Official IEEE publication record
  8. lineage

    Research direction

    source abstract asserted

    The architecture treats proactive secure computation and trusted restoration as a cloud control substrate, anticipating a broader self-healing CloudCOP line.

    Complete author-uploaded source abstract

Source index

Locators state the depth of the current audit. PDF page numbers, where present, are one-based file pages; metadata-, summary-, and abstract-bounded records explicitly identify their limitations.

  1. Complete author-uploaded source abstract ResearchGate abstract; author content uploaded 2016; body not audited
  2. Official IEEE publication record HST 2013, pages 390-395
  3. Dated OpenAlex citation snapshot cited_by_count = 2, accessed 2026-07-11