Attest
Collect platform evidence and preserve raw provider artifacts for backend verification.
Mobile trust layer
A low-friction trust layer for mobile apps.
Project Digitalis verifies runtime signals, keeps trust decisions on the backend, and unlocks protected configuration only after startup conditions are acceptable.
Verification lock
ALLOW
01
Collect evidence
Apple App Attest or Google Play Integrity
02
Verify server-side
Backend-authoritative policy and TTL
03
Unlock protected config
Signed, encrypted, versioned, auditable
Cross-platform
One control flow
Unified provider abstraction for Apple and Google without flattening assurance differences.
Backend-authoritative
One decision layer
The client gathers evidence. The backend decides allow, deny, degrade, or retry.
Low friction
One additive layer
Designed to sit in front of protected features without forcing a full platform rewrite.
Architecture
A startup sequence designed to fail closed.
The RFCs describe Project Digitalis as a trust bootstrap runtime. The app is treated as exposed until attestation, verification, policy, config retrieval, and secure installation all complete.
Verify
Normalize, bind nonces, enforce freshness, and map results to deterministic policy.
Deliver
Return signed and optionally encrypted config only after the backend authorizes it.
Install
Store protected material in hardware-backed facilities and prevent silent rollback.
Designed to layer in
An extra security layer that does not ask you to rebuild everything.
Project Digitalis is easiest to understand as an additive control surface. It can sit in front of existing backend logic, preserve a customer-managed backend model, and make startup trust decisions explicit without pretending the client is authoritative.
Open backend model
Digitalis-operated and customer-managed backends can share one contract and one semantic outcome model.
Useful before deeper hardening
Attestation, signed config delivery, and startup containment add value even before heavier runtime protection is introduced.
Explicit over magical
Capabilities, degradation, retries, and denials are visible and policy-controlled rather than hidden behind SDK optimism.
Security controls
A layered defense stack for harder, shorter-lived bypasses.
Project Digitalis combines client hardening, protocol safeguards, short-lived trust, and verified secure storage so protected behavior is never hanging on a single check.
Binary obfuscation and anti-tampering
Raises the cost of patching, replaying, and bypassing modified app logic.
Nonce-bound attestation
Binds verification to fresh challenges so captured evidence is harder to replay or reuse out of context.
Periodic refresh and short-lived trust
Re-checks runtime posture and limits how long a previously valid result can keep protected behavior unlocked.
Verified config delivery
Uses signed, versioned, and policy-bound configuration so the payload itself remains part of the trust model.
Anti-rollback and version enforcement
Rejects stale packages and incompatible capability profiles so weaker states are not silently reintroduced.
Hardware-backed secure storage
Anchors approved sensitive material in hardware-backed storage after verification succeeds, where the platform supports it.
Outcome model
Deterministic startup behavior under success, denial, and failure.
Equivalent upstream conditions should produce equivalent outcomes. Protected features stay off unless startup reaches an allowed trusted state.
ALLOW
Trust bootstrap succeeded. Valid config is active. Protected features are enabled.
ALLOW_DEGRADED
Only policy-approved non-sensitive behavior may continue. Protected features remain off.
RETRYABLE_FAILURE
Temporary failure. Retry is allowed. The app enters a containment path instead of guessing.
DENY_POLICY
Backend policy rejected the environment. Blocking UI and timed exit become deliberate controls.
DENY_INTEGRITY
Config, evidence, or runtime integrity is unsafe. Protected capabilities stay disabled.
UNSUPPORTED_ENVIRONMENT
Capabilities or secure storage requirements cannot be met. No hidden fallback path.