The Case for Capability-Based Security

Why Policy Assertions Are Insufficient for Data Sovereignty

Version: 1.0 Status: Position Paper Audience: Security Architects, CISOs, Procurement Teams

---

Executive Summary

Security claims fall into two categories:

Type	Basis	Verification	Example
Policy-Based	"We promise not to"	Trust provider's word	"We don't access your data"
Capability-Based	"We cannot"	Verify technical architecture	"We lack the components to decrypt"

The ZKS position: Policy-based security assertions are insufficient for data sovereignty because they can be violated, overridden, or compelled. Only capability-based constraints provide verifiable protection.

---

The Problem with Policy-Based Security

What Policy-Based Security Looks Like

Common policy-based security claims:

"We use industry-leading encryption to protect your data."

"Our employees cannot access your files without authorization."

"We will never share your data with third parties."

"Your privacy is our top priority."

These statements describe intent and policy - what the provider promises to do (or not do).

Why Policy Is Insufficient

1. Policies Can Be Violated

Policy: "Employees cannot access customer data"

Reality:
- Privileged employees can bypass controls
- Audit logs can be deleted
- "Emergency access" procedures exist
- Insider threats are real

Case study: Numerous breaches have involved employees violating stated policies, from social media companies accessing user accounts to cloud providers with "incidental" data access.

2. Policies Can Be Changed

Policy (2023): "We will never scan your encrypted files"
Policy (2024): "To improve security, we now scan files for malware"
Policy (2025): "To comply with regulations, we scan for prohibited content"

Users who relied on the 2023 policy have no recourse when it changes. The data they uploaded under one policy is now subject to another.

3. Policies Can Be Overridden

Policy: "We require a warrant to access user data"

Override scenarios:
- National Security Letter (no warrant, gag order)
- Foreign government request
- "Emergency" disclosure exception
- Corporate acquisition by entity with different policies

Policies are subject to legal, corporate, and political pressures that users cannot anticipate or control.

4. Policies Cannot Resist Compulsion

Court order: "Produce the plaintext of user X's files"

Policy-based response: "We don't want to, but we can, so we must."

Capability-based response: "We cannot comply. We lack the technical
capability to decrypt. Here is our architecture documentation."

This is the fundamental divide: a provider who can decrypt will eventually be compelled to decrypt, regardless of policy.

---

The Capability-Based Alternative

What Capability-Based Security Looks Like

Capability-based security claims:

"We do not possess the encryption keys for your data."

"Our architecture prevents any employee from decrypting customer files."

"The complete set of components necessary for decryption never exists on our infrastructure."

"We cannot comply with decryption demands because we lack the technical capability."

These statements describe technical constraints - what the provider cannot do, regardless of intent.

Why Capability Is Sufficient

1. Capabilities Cannot Be Violated by Intent

Capability: "We do not possess decryption keys"

Employee with malicious intent:
- Cannot decrypt (no keys)
- Cannot bypass (nothing to bypass)
- Cannot access plaintext (plaintext doesn't exist on provider systems)

The constraint is architectural, not procedural. Bad actors are constrained by physics, not policy.

2. Capabilities Cannot Be Changed Retroactively

Capability (2023): "Your data is encrypted client-side; we never see keys"

New management (2024) wants to change this:
- Can only affect NEW data with NEW architecture
- EXISTING data remains protected by original capability
- Cannot retroactively gain access to data encrypted without their keys

Capability-based protection is permanent for data created under that architecture.

3. Capabilities Cannot Be Overridden by Authority

Court order: "Produce the plaintext of user X's files"

Technical response:
1. "We do not possess the plaintext"
2. "We do not possess the decryption keys"
3. "We cannot comply because we lack the capability"
4. "Here is our architecture documentation proving this"

Judges may be skeptical, but technical impossibility is a defense that policy ("we promise not to") never provides.

4. Capabilities Resist Compulsion

The strongest legal protection is not a policy against compliance - it's the inability to comply.

Demand	Policy Response	Capability Response
"Decrypt this file"	Comply (unwillingly)	Cannot comply (no keys)
"Give us the keys"	Comply (with protest)	Cannot comply (we don't have them)
"Install a backdoor"	Comply (under duress)	Future data affected; past data still protected

---

Verifying Capability vs. Policy

Verifying Policy

To verify a policy-based claim, you must:

1. Trust the provider's statement
2. Audit their compliance (if they permit)
3. Hope they don't change the policy
4. Assume they can resist compulsion
5. Believe no insider will violate it

This is fundamentally trust-based verification.

Verifying Capability

To verify a capability-based claim, you can:

1. Examine the architecture
2. Analyze what components exist where
3. Prove that decryption is impossible with available components
4. Confirm through cryptographic analysis
5. Test by attempting decryption with provider access only

This is fundamentally evidence-based verification.

The Falsifiability Principle

Claim Type	Falsifiable?	How to Disprove
"We don't access your data"	Difficult	Catch them accessing (may be hidden)
"We can't access your data"	Yes	Show they possess components for access

Capability-based claims are scientifically falsifiable. Policy-based claims are not - you can never prove a negative ("they never accessed the data").

---

The Coexistence Problem

Policy Approach to Coexistence

Provider holds: Ciphertext + Wrapped Keys

Policy claim: "We have keys, but they're encrypted. We can't use them
without the wrapping key, which we don't have."

Problems:
- Wrapping could be broken (now or future)
- Wrapping key could be obtained (coercion, breach)
- Provider is ONE component away from decryption
- "Harvest now, decrypt later" remains viable

Policy says they won't combine the components. But they could.

Capability Approach to Coexistence

Provider holds: Only Ciphertext (no key components)

OR

Provider holds: Only Wrapped Keys (no ciphertext)

Capability claim: "We cannot decrypt because we lack the necessary
components. Even if we tried, we would need components we don't have."

Advantages:
- Missing components cannot be fabricated
- No "one step away" vulnerability
- "Harvest now" has nothing to decrypt later
- Coercion yields nothing useful

Capability ensures they cannot combine components - because they don't have them all.

---

Real-World Examples

Example 1: Email Provider

Policy-based (typical):

Provider holds: Encrypted emails + Password-derived key
Policy: "We can't read your email without your password"

Reality:
- Password entered via provider's web interface
- Provider could capture password if they chose
- Provider could serve modified JavaScript
- Policy is all that prevents this

Capability-based (ZKS):

Provider holds: Encrypted emails only
User holds: Decryption keys on device only

Reality:
- Password never transmitted to provider
- Key derivation happens client-side only
- Provider cannot capture password (never receives it)
- Capability prevents access, not policy

Example 2: Cloud Storage

Policy-based (typical):

Provider holds: Encrypted files + Customer-managed keys (in provider HSM)
Policy: "Your keys are in an HSM we can't access"

Reality:
- Provider operates the HSM
- Provider could extract keys (difficult but possible)
- Provider could be compelled to try
- Coexistence means components can be assembled

Capability-based (ZKS):

Provider holds: Encrypted files only
User holds: Keys on user devices / user-controlled storage

Reality:
- Keys never touch provider infrastructure
- No HSM extraction risk (no HSM needed)
- Compulsion yields only ciphertext
- Components cannot be assembled - provider doesn't have them

Example 3: Messaging

Policy-based (typical):

Provider holds: Message metadata + Key distribution infrastructure
Policy: "We use end-to-end encryption; we can't read messages"

Reality:
- Provider distributes keys via their servers
- Provider could MITM key exchange
- Provider could push malicious client update
- Policy is the only barrier

Capability-based (ZKS):

Provider holds: Routing metadata only
User holds: Keys via verified key exchange (out-of-band verification)

Reality:
- Key exchange verified independently of provider
- Malicious update detectable via binary transparency
- Provider cannot MITM without detection
- Capability + transparency prevent compromise

---

The ZKS Capability Requirements

ZKS codifies capability-based security through specific requirements:

Core Capability Requirements

Assertion	Capability Enforced
A1	Provider cannot decrypt (CSD-only decryption)
A2	Provider cannot possess keys (exclusive user possession)
A3	Provider cannot assemble decryptability (no coexistence)
A4	Provider cannot revoke decryptability (user retains control)

Verification Mechanisms

Requirement	Verification Method
No provider decryption	Architecture analysis (T-CAP-1)
No key possession	Component inventory (T-STR-4)
No coexistence	Topology analysis (T-CAP-5)
No revocation	Service denial test (T-REV-1)

---

Objections and Responses

"But we really don't access user data"

Response: We believe you. But:

• Your successor might not have the same policy
• A court might compel you despite your policy
• An insider might violate the policy
• A breach might expose your capability

The question is not whether you will - it's whether you can.

"Capability-based systems are harder to build"

Response: Yes. That's partly the point. Security through difficulty is more robust than security through restraint.

But also: the architectural patterns for capability-based security are well-established. Client-side encryption, end-to-end encryption, and key separation are proven techniques.

"We need access for support/security/compliance"

Response: Perhaps for some functions. But each access capability is a risk. ZKS asks: which access capabilities are truly necessary, and which can be eliminated through architecture?

Often, "necessary" access is actually "convenient" access that could be re-architected.

"Users might lose their keys"

Response: This is a real concern, addressed by ZKS through:

• User-controlled recovery mechanisms
• Multi-device key sync
• User-held backups

The key is user-controlled recovery - not provider-controlled. See A9 (UKRS) for compliant recovery patterns.

---

Recommendations

For Evaluating Vendors

When evaluating security claims:

Question	Policy Answer (Weak)	Capability Answer (Strong)
"Can you read my data?"	"No, we don't do that"	"No, we lack the components"
"What if you're hacked?"	"We have strong security"	"Attacker gets only ciphertext"
"What if you're subpoenaed?"	"We'll fight it"	"We cannot comply technically"
"Where are my keys?"	"Secure in our HSM"	"Only on your devices"

For Architects

When designing systems:

1. Default to capability - Assume policy will fail; design for technical constraints
2. Eliminate coexistence - Never hold both data and key components
3. Verify through architecture - Document why decryption is impossible
4. Plan for compulsion - Design so you cannot be compelled

For Procurement

When writing RFPs:

1. Require capability claims - "Demonstrate technical inability to decrypt"
2. Reject policy claims - "We promise not to" is insufficient
3. Demand architecture documentation - Verify claims are capability-based
4. Include ZKS compliance - Use the standard as a baseline

---

Conclusion

The fundamental difference between policy-based and capability-based security:

Aspect	Policy-Based	Capability-Based
Foundation	Trust	Architecture
Verification	Audit compliance	Analyze structure
Durability	Until policy changes	Permanent for existing data
Compulsion resistance	None	Complete
Insider resistance	Limited	Complete
Falsifiability	No	Yes

ZKS mandates capability-based security because only technical constraints provide verifiable, durable, compulsion-resistant protection.

Policy says: "We won't." Capability says: "We can't."

Only one of these survives a subpoena.

---

References

• ZKS-1.0: Zero-Knowledge Sovereignty Standard
• Anderson, R. "Security Engineering" (capability vs. policy discussion)
• Schneier, B. "Secrets and Lies" (trust and verification)
• Diffie & Landau, "Privacy on the Line" (lawful access and technical constraints)