A host that cannot simply read the work.
The hardware direction is a different security boundary from an ordinary application. A general-purpose operating system should be able to transport encrypted content and request an operation, without receiving the protected content key or the plaintext needed to perform that operation. The protected endpoint would decide whether the particular request is authorised, process only the permitted unit and expose only the permitted output.
For a book, the intended reader would decrypt the authorised page inside its protected boundary, present that page through a controlled display path, and retire the transient state when the page closes or its authority expires. It would not decrypt the complete book into an application buffer. For video, the unit could be a frame or a tightly bounded decode window. For structured information, it could be a record, field or computation over a defined input. The boundary and output policy would depend on the medium.
Design objective, not an alpha claim. No host-OS access to protected keys or plaintext, narrow per-unit processing, and protected display/computation are future requirements to be tested against a named hardware implementation. The current alpha executes in ordinary software and does not satisfy them.
The point is to make possession enforceable at the place where information becomes usable. A ledger alone cannot stop a compromised operating system from reading a decryption buffer. A secure element alone cannot protect plaintext when a cryptographic operation returns plaintext or a usable shared secret to ordinary application memory. The complete execution and input/output path must uphold the same policy.
Authorise a unit. Keep the rest encrypted.
The proposed content pipeline divides a work into independently protected units with an authenticated manifest. A unit must be unambiguously bound to its work identifier, index or range, content version, applicable policy and intended processing context. This prevents a permitted request for one unit from silently turning into authority over another unit or another edition.
- Keep the complete work encrypted.The ordinary storage and transport path can hold ciphertext and a manifest. It does not need a full-work plaintext copy in order to deliver the next authorised unit.
- Validate a narrow request.The protected endpoint checks ownership/access evidence, recipient identity, content identity, operation, freshness and the currently accepted policy before requesting or accepting usable contributions.
- Process a bounded working set.Key use and decryption take place in protected memory. A book reader might hold one page plus strictly necessary rendering data; a codec might require a documented short dependency window. The permitted bound must be measured, not assumed. No whole-work plaintext object is assembled anywhere in the proposed reader.
- Control the output path.A display operation sends pixels only to the approved protected display path. A computation exposes only its defined result. An unrestricted export, debug dump or general-purpose plaintext API would defeat the objective.
- Retire transient authority.On expiry, page close, interruption, transfer or a required failed check, the endpoint clears transient buffers and invalidates the corresponding session state according to its policy. Tests must cover registers, caches, intermediate buffers and crash paths as well as the obvious heap allocation.
Unit-level access limits simultaneous plaintext exposure; it does not mean an authorised reader can never learn an entire book by reading its pages. A camera, transcription or an overly revealing computation can reproduce information after an authorised output. Output minimisation and protection against digital extraction are useful, bounded goals; eliminating every analogue or semantic copy is not.
For a reflowable ebook, visual pages change with font and viewport. Authorisation must bind authenticated content-unit identifiers or ranges, with a displayed page mapped to a bounded permitted set.
Granularity is an engineering trade-off. Smaller units reduce exposure and permit finer control, but require more authorisation decisions, manifest entries and transitions. Media with cross-frame prediction, search, accessibility or indexing needs explicit treatment rather than an informal exception that quietly exposes the whole work.
Competing services. An indispensable device.
The planned next architecture would combine remote threshold services with a compulsory protected-device contribution. Eligible remote providers could compete to perform the required service, while the device admits only an authorised, bounded display or computation. The intended conjunction is remote participation and the approved hardware, not either one acting as an unrestricted substitute for the other.
Three separate decisions must remain explicit: which remote combination may perform the cryptographic operation; what makes the protected device indispensable; and how eligible providers are selected or rewarded. Provider competition may improve cost, availability, capacity or latency, but does not itself establish threshold security, independent administration or blockchain consensus.
Remote threshold
Verified contributions from the required independent parties. No single provider should unlock the work.
Protected device
A separately protected device contribution, bound to the approved endpoint and operation.
Bounded operation
Only the permitted unit and protected working set become usable; no whole-work plaintext object.
Encrypting an honest provider’s response to a device protects that delivery route. It does not prove that a malicious qualifying quorum cannot reconstruct the relevant result elsewhere. The current alpha explicitly exposes this colluding-quorum boundary. Making the hardware indispensable even against that coalition needs a separately reviewed construction with an independent device-bound secret or contribution; honest-server policy alone is insufficient.
The future design must also state what each remote participant learns. Threshold key operations, secure multiparty computation and hardware-isolated computation have different security obligations. A threshold-controlled key operation is not automatically a general confidential-computation service. Any proposed computation needs a defined function, input privacy/corruption model, intermediate-state policy and permitted outputs.
Competition must preserve eligibility. Multiple addresses can belong to one operator, and apparently different providers can share infrastructure or fail together. Selection must address common control, correlated failure and attempts to occupy several participant positions. A cheaper or faster answer cannot bypass cryptographic checks or state freshness.
Enrollment and replacement affect key material as well as scheduling. New capacity cannot simply join an existing share set without an authenticated membership transition. Retired providers and old shares must not regain authority after rollback. During an outage, the system must not lower its required threshold or fall back to an unrestricted cached key merely to keep a request moving. No bidding mechanism, fee, reward formula or production threshold is announced here.
Tests for the conjunction
- Quorum without device: give a malicious qualifying coalition retained ciphertext and verify the exact property preventing bypass of the required hardware, or state that the property is not met.
- Device without quorum: remove or corrupt remote participation and test that the endpoint cannot silently downgrade the requirement.
- Wrong recipient: relay valid evidence or envelopes to a different endpoint; the assessed protected recipient must remain bound to the operation.
- False provider diversity: exercise common-control identities, correlated outage and membership changes rather than count endpoints as independent by assumption.
- Competitive substitution: offer faster, cheaper, stale or malformed contributions and verify that selection never replaces correctness checks.
- Exposure and output: inspect remote and host views, intermediate state and repeated outputs. No whole-work plaintext object should emerge, and allowed computation results must not create an unintended export API.
General cryptographic context: NIST Multi-Party Threshold Cryptography. The provider competition and compulsory-device composition described here are INTEGYRS design objectives, not claims of a completed NIST-reviewed protocol.
A small fixed root. A controlled update path.
A promising device starts with a minimal trust anchor below the ordinary operating system. Depending on the hardware, its first instructions or verification material may be placed in mask ROM, one-time-programmable storage, or fuses whose permitted changes are constrained by the silicon. Such mechanisms can make a defined root resistant to ordinary software rewriting after provisioning.
That is the useful meaning of the long-term “cannot be overwritten” objective: ordinary host software must not be able to replace the root that decides which protected code is allowed to run, reset the ownership/security history, or substitute its own decryption policy. It is not a claim that every component is physically unmodifiable, that all manufacturing processes are trustworthy, or that a device can never be defeated.
Minimal root
Boot verification logic, root verification material and device lifecycle policy.
Protected firmware
Signed code, accepted-version floor, recovery rules and measured configuration.
Unit authorisation
Current possession evidence, recipient binding, permitted operation and expiry.
Protected execution
Verify, derive, decrypt and compute inside the selected isolation boundary.
Display or result
No protected plaintext or key in host buffers; no whole-work plaintext object anywhere.
Clear & advance
Clear transient material; retain protected evidence needed to reject rollback.
Mechanism examples: Trusted Firmware-A Trusted Board Boot and Samsung Knox hardware-backed security. They establish architectural options, not implementation or certification of INTEGYRS hardware.
A fixed root still needs a survivable design around it. Firmware contains bugs; cryptographic algorithms and keys have lifecycles. The system should distinguish the small anchor that must remain stable from components that need authenticated updates, recovery and controlled key rotation. Permanently freezing all application code would create its own security and maintenance failures.
Engineering basis: NIST SP 800-193, Platform Firmware Resiliency Guidelines, describes roots and chains of trust for protection, detection and recovery. The INTEGYRS composition above is a proposed application of those principles, not NIST validation or certification.
Knowing what runs is part of authorising it.
Verified boot and measured boot answer related but different questions. Verification can refuse an unauthorised next stage before executing it. Measurement records the identity of loaded components so a verifier can assess them. A complete access decision also needs a policy saying which combinations of software version, debug state, lifecycle state and security configuration are acceptable.
Remote attestation would connect a fresh challenge to evidence about a particular endpoint and its trusted state. The verifier must validate the attestation chain, challenge binding, device/recipient relationship, relevant measurements and current revocation policy. Accepting a self-reported string such as “secure mode” is not attestation. Accepting a genuine attestation for the wrong application, an old challenge or an unacceptable firmware version is not sufficient either.
The endpoint receiving a content contribution must be the endpoint whose state was assessed. Otherwise, a sound device could attest while a different process receives the usable secret. The binding has to survive the whole route from verifier decision through key agreement and protected use.
Attestation also creates operational and privacy obligations: who issues and revokes credentials, how compromised batches are handled, whether devices can be tracked across uses, how policy updates are authenticated, and what happens when a manufacturer or verifier is unavailable. These are system-design questions, not benefits automatically provided by buying a chip.
Attestation architecture: IETF RFC 9334, Remote ATtestation procedureS, distinguishes evidence, appraisal policy and relying-party decisions.
Platform example: Android Open Source Project: Verified Boot explains a hardware-rooted verification chain and rollback protection. This is a reference model, not evidence that a particular Android or Samsung device implements the complete INTEGYRS protected path.
An intact old state can still be wrong.
Integrity alone does not establish recency. An attacker may restore a perfectly signed, previously valid image or possession snapshot. At least three distinct rollback problems have to be addressed.
| State | Attack | Required design evidence |
|---|---|---|
| Firmware version | Boot an older signed image with a known weakness. | A protected minimum-version policy, authenticated updates and recovery that cannot silently lower the security floor. |
| Possession and transfer state | Restore an old owner/session snapshot after the possession has moved. | Fresh authenticated ownership evidence and protected local state tied to the accepted succession history. |
| Access/session state | Replay a consumed capability, old receipt, expiry value or page buffer. | Operation binding, replay prevention, monotonic session state where needed, and tested retirement of transient material. |
A hardware monotonic counter or protected version floor can help stop a local state value moving backwards. It does not establish that a remote ledger observation is current, that an owner has not transferred elsewhere, or that the endpoint has seen every relevant event. Conversely, an online observer does not by itself prevent a compromised device from restoring an old internal buffer.
The design must define power-loss behavior and the atomic boundary between accepting authority, updating protected state and producing output. If these steps straddle a crash, recovery needs an explicit answer: resume a recorded authorised operation, refuse it, or reconcile with fresh evidence. “Retry” is not a complete protocol rule.
Reference mechanisms: AOSP Verified Boot explains rollback protection, and Samsung hardware-backed security describes rollback-prevention fuses. These are implementation examples, not a chosen INTEGYRS platform or proof of its complete state-freshness policy.
A protected key is not a protected reader.
Keeping a private key in a secure element is useful, but insufficient if the operating system can ask it to decrypt arbitrary content into ordinary RAM. Similarly, an isolated process is insufficient if a screen-capture service, GPU buffer, DMA-capable peripheral or crash reporter can retrieve the resulting plaintext or pixels outside the accepted boundary.
The intended endpoint must specify where each transformation occurs: recipient proof verification, contribution verification, key derivation or reconstruction, authenticated decryption, document parsing or media decoding, layout/computation, display composition and output. Each transition needs an explicit rule for what may cross into the untrusted host.
Vendor feasibility is a separate acceptance gate. The presence of a TEE, StrongBox or Knox does not establish that a third-party application on a particular handset can install this custom trusted reader or use all required protected rendering APIs. Device model, firmware, provisioning, vendor-supported access and end-to-end protected I/O must be demonstrated; unsupported paths must fail closed.
Mechanism references: Android Keystore, AOSP protected graphics buffers, and GlobalPlatform low-level Trusted User Interface. These describe different components, not a ready-made INTEGYRS reader or universal handset capability.
A practical design may permit the host to handle encrypted bytes, nonsecret scheduling data, ciphertext caches and narrowly defined status codes. Sensitive intermediate state must remain inside the tested boundary. Whether glyph caches, thumbnails, accessibility output, search indexes or codec reference frames are sensitive depends on what they reveal. Treating them as harmless metadata without analysis would undermine the page-by-page objective.
Authorised computation needs a similar discipline. “The plaintext never leaves” is inadequate if the operation returns the original document, an arbitrary memory range, or enough unrestricted queries to reconstruct it. The permitted function, output precision, query budget and session identity become part of the security policy.
Protection offered today: bounded software-model authorization and refusal behavior. Protection sought in hardware: prevent an ordinary compromised host from extracting protected keys or plaintext and from replacing the controlling policy. The latter is a development objective awaiting adversarial evidence.
The full test starts with an attacker in control.
The proposed evaluation begins by assuming the ordinary host operating system is malicious. The evaluator should be able to inspect host RAM and persistent storage, instrument drivers, replay traffic, kill processes, trigger resets and manipulate every host-controlled input. Passing a normal reading demonstration does not establish the desired boundary.
| Attack surface | Attempt | Pass condition to demonstrate |
|---|---|---|
| Host memory and storage | Inspect RAM, swap, dumps, logs, caches and temporary files while rendering and after termination. | No protected-content plaintext or protected key appears outside the declared boundary; only specifically permitted output is released. |
| Debug and manufacture state | Use debug ports, development firmware, lifecycle transitions and unauthorised reflash attempts. | Unsupported/debug-unlocked states fail policy; production provisioning cannot be reversed by normal host control. |
| DMA, I/O and graphics | Probe DMA-capable paths, display/compositor buffers, peripherals and screen-capture APIs. | Protected content cannot be read through tested untrusted I/O routes; excluded physical capture is stated. |
| Rollback and interruption | Restore snapshots; change the clock; reboot between authorisation, state commit and output. | No old possession or weaker firmware state silently regains fresh authority; crash recovery obeys the defined ordering. |
| Faults and side channels | Apply scoped fault injection and timing/power analysis appropriate to the device profile. | Evidence meets the declared resistance level; untested invasive attacks remain outside the claim. |
| Per-unit containment | Request adjacent pages, oversized ranges, malformed manifests and unauthorised operations. | Only the authorised unit or documented working window is processed; no whole-work plaintext object is assembled anywhere; only the declared bounded protected working set exists. |
| Transfer and expiry | Freeze while rendering; disconnect observers; delay valid messages; retain old capabilities. | Fresh operations obey current policy and the declared in-flight boundary; no instant recall of prior output is claimed. |
| Zeroization and recovery | Crash during decode/render, rotate keys and exercise lost-device/recovery paths. | Retired state does not become a reusable decryption route; recovery neither clones current possession nor silently weakens the trust anchor. |
Results should identify the hardware revision, boot chain, firmware image, compiler/build configuration, attestation policy, test equipment, attacker access and exclusions. A failed or unavailable test narrows the supported claim. Independent evaluation is part of the intended assurance path; none is claimed as completed here.
Recovery must not become a hidden master key.
Device replacement, owner-key recovery, firmware recovery and committee-key rotation solve different failures. They must not share an undocumented override that can decrypt every past work. Replacement should establish a new eligible endpoint and retire the old endpoint’s fresh authority, while recovery authority must be defined before a user loses the only key required to exercise it.
A future recovery design needs explicit proofs, who may approve them, how competing requests are challenged, any waiting or quarantine period, and how the accepted transition becomes visible to observers and access nodes. Compromised keys require an emergency path, but an emergency path also needs an attacker model. Convenience cannot be purchased by silently creating an all-powerful custodian.
Signed firmware updates should be evaluated as changes to the protected policy, not merely file replacements. The device must know which signing authority is allowed to update which component, which security versions are acceptable, and how a compromised signing key is retired without reopening a weaker image. A fixed root can anchor controlled evolution; it cannot remove the need to govern that evolution.
See the recovery map for lost-device, sole-key loss, compromise and key-rotation scenarios. The current software profile does not recover a lost sole owner signing key.
Less exposure has a real engineering cost.
Protected hardware, provisioning, key custody, verified updates and independent testing cost money. Per-page or per-frame checks also consume computation, bandwidth and energy, and introduce latency and failure dependencies. INTEGYRS does not publish a device price, transaction budget, throughput guarantee or service tariff at this stage.
The engineering task is to measure these costs against the required boundary: the size of a protected working set, the rate of authorisation, observer latency, committee availability, attestation frequency, media decode needs, recovery effort and long-term firmware support. A lower-cost configuration may have a narrower assurance claim; that trade-off should be visible.
The longer-term direction is a family of security devices and protected execution profiles in which recognised ownership governs specific uses of information. Readers, controlled computation, licensed data access and device-bound entitlements are possible directions, not announced production products. Each requires its own rights model, output policy and evidence.
Software defines the intended state machine and makes failure behavior testable. Hardware may later move the enforcement boundary beyond the host operating system. The transition is successful only when the same policy survives hostile-host testing, interrupted operation and the full lifecycle of the device.