Time is divided into rounds. Between rounds, old shares are rerandomized and removed so compromises collected in different periods cannot be combined; the represented goal is long-term data confidentiality rather than a general cloud integrity or availability service.

1. threat model

   Passive mobile compromise adversary

   defined

   The honest-but-curious outside adversary may compromise different servers over time and eventually visit all of them, but fewer than one third in any round. It cannot globally monitor traffic, delay traffic it did not send, create servers, corrupt multiple hypervisors, break the Internet, or orchestrate system-wide denial of service.

   Passive mobile-adversary model
2. assumption

   Underlying packed PSS guarantee

   inherited security assumption

   The implementation instantiates a perfectly secure packed PSS scheme with constant amortized communication per share. Its privacy and robustness parameter constraints include l + t at most d and 3t + l less than n.

   Packed proactive secret sharing and parameter constraints
3. assumption

   Trusted lifecycle mechanisms

   assumed

   Security relies on read-only pristine images, authenticated fresh keys, controlled VM creation, scheduled reboot, bounded network delay, and secure disassociation that prevents a restarted VM from accessing storage and RAM associated with earlier rounds.

   Secure reboot, key replacement, restart schedule, and disassociation · Broadcast, timing, network, and share-storage assumptions

A client shares files among n storage hosts; hosts keep inactive shares in secondary storage, periodically load batches into memory, execute recovery and refresh, and write new shares back. The client may disconnect between upload and reconstruction.

1. method

   Three deployment patterns

   proposed

   The design covers a single cloud provider, multiple providers, and a hybrid of local enterprise infrastructure with remote providers. Only the single-provider arrangement is the reported prototype deployment.

   Problem, contribution, and deployment scenarios · EC2 testbed, varied parameters, performance, and cost
2. protocol

   Proactive server lifecycle

   specified

   The hypervisor creates hosts from a read-only image, allocates shares, shuts down and reclaims resources, initializes a replacement with fresh authenticated keys, and lets peers recover and rerandomize its shares according to a predetermined rotation schedule.

   PiSCES components and five-stage server lifecycle · Secure reboot, key replacement, restart schedule, and disassociation
3. protocol

   Epoch key secrecy

   specified with alternatives

   The prototype assumes TPM-backed or hypervisor-installed fresh keying material so a key learned in period i cannot forge or decrypt period-j traffic. The paper also discusses pre-uploaded signed key pairs as a way to reduce hypervisor computation.

   Packed proactive secret sharing and parameter constraints · Secure reboot, key replacement, restart schedule, and disassociation

The paper combines inherited PSS confidentiality with systems assumptions and empirical feasibility evidence. The cryptographic, architectural, and measured claims have different support and should not be collapsed into one guarantee.

1. claim

   Long-term confidentiality against mobile compromise

   conditional on model

   If fewer than the tolerated servers are exposed within any refresh period and old state, keys, and adversarial presence are removed at the boundary, observations from different periods do not combine to reveal the protected file.

   Passive mobile-adversary model · Packed proactive secret sharing and parameter constraints · System security analysis and hypervisor boundary
2. claim

   Larger-file and tens-of-host feasibility

   implemented and measured

   The prototype exercises files beyond cryptographic-key sizes and configurations up to 30 servers, including a t = 9 threshold point, showing that the selected PSS can operate at a scale not previously exercised by the cited PSS implementations.

   Packed proactive secret sharing and parameter constraints · EC2 testbed, varied parameters, performance, and cost
3. claim

   Deployment-specific cost feasibility

   reported measurement

   The lessons-learned section reports, for one tuned configuration, storage of a 10-kilobyte object at approximately 0.08 cents per kilobyte per refresh; it does not claim that this price generalizes across clouds, dates, objects, or assurance settings.

   Lessons learned, selected configuration, and conclusions

Evidence includes the inherited packed-PSS conditions, an architectural security analysis, an implemented multi-host prototype, an automated EC2 benchmarking driver, and parameter sweeps over security, file, restart, packing, threading, and field-size choices.

1. evidence

   Amazon EC2 testbed

   reported experiment

   The experiments use dedicated EC2 Small, Medium, and Large instances and an outside driver that creates deployments and initiates measurements. Dedicated hosts reduce interference but differ from the lower-priced instances anticipated for practical operation.

   EC2 testbed, varied parameters, performance, and cost
2. evidence

   Parameter exploration

   systematic parameter study

   The study varies n, tolerated corruptions t, file size s, simultaneous restarts r, packing l, concurrent refreshed shares b, and field size g. It identifies t and refresh interval as especially consequential and reports n = 21, t = 4, l = 6, r = 3, g = 1024 as its best tested selection.

   EC2 testbed, varied parameters, performance, and cost · Lessons learned, selected configuration, and conclusions
3. evidence

   Security analysis boundary

   architectural argument

   The paper reasons about hypervisor compromise, secure broadcast, reboot authentication, and stale-state isolation, but the represented source does not supply a composable end-to-end proof that the concrete cloud implementation realizes the ideal PSS model.

   System security analysis and hypervisor boundary

PiSCES trades long-term confidentiality for periodic computation, many hosts, synchronized recovery windows, key and image trust, and provider-dependent state isolation. Parameter selection is non-obvious, and more hosts can improve threshold efficiency while increasing fleet complexity and idle cost.

1. limitation

   Passive-adversary and availability boundary

   explicitly out of scope

   The core evaluation does not establish Byzantine robustness against arbitrary active deviations, multi-hypervisor compromise, global traffic observation, Internet failure, or denial of service. Manual recovery may be required after some assumed-away platform failures.

   Passive mobile-adversary model · System security analysis and hypervisor boundary
2. limitation

   Disassociation is not assured deletion

   weakened requirement

   Because commercial clouds did not provide guaranteed erasure, the design substitutes probabilistic or architectural disassociation: a new VM must not regain physical access to the prior round's RAM or disk. This is a key assumption, not a measured deletion guarantee.

   Broadcast, timing, network, and share-storage assumptions