192 lines
5.3 KiB
Markdown
192 lines
5.3 KiB
Markdown
# Decentralized Hub Ownership and Recovery Design (PKI-Based, No Blockchain)
|
||
|
||
## 1. Keys and DIDs (Conceptual Model)
|
||
|
||
For each Hub, define three logical components:
|
||
|
||
### 1. Hub Owner Key (Kₒ)
|
||
|
||
- Long‑term key pair defining the **owner** of the Hub DID.
|
||
- Private key never leaves the user's devices.
|
||
- DID example: `did:key:<public-of-Kₒ>`.
|
||
- Ultimate authority for the Hub.
|
||
|
||
### 2. Hub Operational Key (Kₕ)
|
||
|
||
- Key pair used by the **server instance** running the Hub.
|
||
- Private key stored on the Hub backend server.
|
||
- Granted authority via a signed **delegation certificate** from Kₒ.
|
||
|
||
### 3. Recovery Secret / Code (R)
|
||
|
||
- High‑entropy secret generated **client-side** (NextJS).
|
||
- Used to derive Kₒ (e.g., `Kₒ = KDF(R, "hub-owner")`).
|
||
- Shown **only once**.
|
||
- **Never stored on any server.**
|
||
|
||
### Additional Component: Passport DID (Dᴘ)
|
||
|
||
The user's self-sovereign identity. Contains a verifiable claim linking
|
||
the user to ownership of the Hub DID.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## 2. Creating a Hub and Binding Ownership to a Passport
|
||
|
||
### Step 1: Generate Owner Identity (Client-Side)
|
||
|
||
1. Generate random secret `R`.
|
||
2. Derive owner key pair `Kₒ`.
|
||
3. Compute Hub DID: `Dᴴ = did:key:<pub(Kₒ)>`.
|
||
4. Show recovery code R to user for offline storage.
|
||
|
||
### Step 2: Create Operational Identity (Server-Side)
|
||
|
||
1. Server generates new key pair `Kₕ`.
|
||
2. Client fetches `pub(Kₕ)` securely.
|
||
|
||
### Step 3: Delegate Authority (Client → Server)
|
||
|
||
Create a delegation certificate:
|
||
|
||
{
|
||
hubDid: Dᴴ,
|
||
delegatedTo: pub(Kₕ),
|
||
privileges: ["serve-hub", "sign-hub-messages"],
|
||
issuedAt: t₀,
|
||
expiresAt: t₁
|
||
}
|
||
|
||
Sign the certificate with `Kₒ`, then upload it to the server.
|
||
|
||
### Step 4: Bind Hub to Owner's Passport
|
||
|
||
Add a verifiable claim:
|
||
|
||
``` json
|
||
{
|
||
"subject": Dᴘ,
|
||
"claim": {
|
||
"type": "HubOwnership",
|
||
"hubDid": Dᴴ,
|
||
"role": "owner"
|
||
}
|
||
}
|
||
```
|
||
|
||
Signed by the Passport key, optionally also by Kₒ.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## 3. Normal Operation
|
||
|
||
When interacting with other Hubs, a Hub sends: - Hub DID (`Dᴴ`) -
|
||
Delegation certificate (`Kₒ → Kₕ`) - Its operational public key
|
||
(`pub(Kₕ)`)
|
||
|
||
Peers verify: 1. Certificate signature matches `pub(Kₒ)` encoded in
|
||
`Dᴴ`. 2. Message signatures match `pub(Kₕ)`. 3. Ownership via Passport
|
||
profile (if desired).
|
||
|
||
**Owner = controls Kₒ**\
|
||
**Server = controls Kₕ (delegated)**
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## 4. Handling a Server Compromise
|
||
|
||
If a hacker takes over the server: - They gain `Kₕ`. - They **do not**
|
||
have `R` or `Kₒ`.
|
||
|
||
The owner must: 1. Launch a new Hub on a new server. 2. Broadcast a
|
||
signed compromise notice. 3. Prove ownership via signatures from `Kₒ`.
|
||
|
||
### 4.1 Reconstructing Kₒ from R (If Needed)
|
||
|
||
User enters recovery code R on a safe device: - Derive
|
||
`Kₒ = KDF(R, "hub-owner")`. - Validate that its DID matches the Hub DID
|
||
Dᴴ.
|
||
|
||
### 4.2 Create New Operational Key (Kₕ′)
|
||
|
||
New server generates `Kₕ′`.
|
||
|
||
Owner creates a new delegation certificate:
|
||
|
||
Kₒ → Kₕ′
|
||
|
||
Owner also signs a **revocation** of the old operational key:
|
||
|
||
{
|
||
hubDid: Dᴴ,
|
||
revokedKey: pub(Kₕ),
|
||
reason: "Server compromised",
|
||
revokedAt: t₂
|
||
}
|
||
|
||
### 4.3 Broadcasting the Recovery
|
||
|
||
New Hub publishes: - `hubDid: Dᴴ` - new endpoint - new `pub(Kₕ′)` - new
|
||
delegation certificate - revocation of `pub(Kₕ)` - optional
|
||
Passport-signed confirmation
|
||
|
||
The attacker cannot: - sign new delegations (requires `Kₒ`) - sign
|
||
revocations (requires `Kₒ`) - change the Hub DID (`pub(Kₒ)`)
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## 5. Trust Decision Model (No Consensus)
|
||
|
||
Each Hub or human owner decides independently what to trust.
|
||
|
||
### Typical Validation Rules
|
||
|
||
1. Accept only messages signed by an operational key currently
|
||
delegated by `Kₒ`.
|
||
2. Respect revocations signed by `Kₒ`.
|
||
3. Track a local chain of:
|
||
- delegations\
|
||
- revocations\
|
||
- Passport claims
|
||
|
||
No global ledger required.
|
||
|
||
### Human Decision Layer
|
||
|
||
Owners may also use: - Out‑of‑band communication - Social trust - Direct
|
||
evidence from the Passport DID
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## 6. Recovery Code Requirements
|
||
|
||
The design satisfies your constraints:
|
||
|
||
- **Never stored on a server.**
|
||
- Generated client-side only.
|
||
- Used only to derive `Kₒ` when recovering ownership.
|
||
- Never transmitted over the network.
|
||
- Attackers cannot derive R or Kₒ from any server compromise.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## 7. Optional Refinements
|
||
|
||
- Multi-sig ownership (`Kₒ` split across devices).
|
||
- Time‑bound delegations.
|
||
- Owner-signed references to external identities (website, company
|
||
DID, etc.).
|
||
- More expressive Passport claims.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## Summary
|
||
|
||
This design provides: - **Hub DID ownership backed by PKI**, no
|
||
blockchain needed. - **Recovery mechanism based on a secret code (R)**
|
||
that never touches servers. - **Revocation and redelegation** driven by
|
||
the owner key (Kₒ). - **Human‑centric trust decisions**, no consensus
|
||
protocol.
|
||
|
||
The attacker cannot permanently hijack a Hub unless they obtain the
|
||
recovery code.
|