RustFS Security Model

RustFS is tasmanian.cloud's S3-compatible object storage with post-quantum cryptography. This document outlines the security model for data confidentiality, integrity, and availability.

---

Security Goals

The RustFS security model aims to provide:

• Confidentiality: Data is encrypted at rest and in transit with post-quantum algorithms
• Integrity: All data is checksummed and tamper-evident
• Availability: Multi-node replication ensures data survives failures
• Access control: Fine-grained IAM policies control data access
• Auditability: All operations are logged for compliance
• Sovereignty: Data never leaves Tasmanian jurisdiction

---

Threat Model

In Scope (Threats We Protect Against)

• Eavesdropping on data in transit: Interception of S3 API traffic
• Storage media theft: Physical theft of drives or nodes
• Node compromise: Attacker gaining access to storage nodes
• Metadata tampering: Modification of object metadata or ACLs
• Unauthorized access: Access without valid credentials
• Replay attacks: Reuse of signed requests
• Bucket enumeration: Discovery of bucket names via brute force
• Data corruption: Bit rot, hardware failures, software bugs
• Insider threats (limited): Operators with legitimate access

Out of Scope (Threats We Do Not Protect Against)

• Compromised customer credentials: If access keys are leaked
• Malicious customers: Customers accessing their own data (expected behavior)
• Application-level vulnerabilities: XSS, SQLi in apps using RustFS
• Side-channel attacks: Timing analysis of encryption operations
• Quantum computers: Our post-quantum crypto is precautionary, not guaranteed
• Physical destruction of all nodes: Complete data center destruction
• Cryptographic breaks: Failure of Kyber, Dilithium, or AES
• Supply chain attacks on hardware: Compromised drives or CPUs

---

External Threat Overview

Architecture Components

┌─────────────────────────────────────────────────────────────────┐
│                         Customer                                │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │   AWS CLI    │  │  Application │  │   SDK        │          │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘          │
└─────────┼────────────────┼────────────────┼────────────────────┘
          │                │                │
          └────────────────┴────────────────┘
                           │
                    ┌──────▼──────┐
                    │  Cloudflare │
                    │  (WAF/DDoS) │
                    └──────┬──────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
   ┌──────▼──────┐  ┌──────▼──────┐  ┌──────▼──────┐
   │ RustFS      │  │ RustFS      │  │ RustFS      │
   │ Gateway 1   │  │ Gateway 2   │  │ Gateway 3   │
   │             │  │             │  │             │
   │ ┌─────────┐ │  │ ┌─────────┐ │  │ ┌─────────┐ │
   │ │ S3 API  │ │  │ │ S3 API  │ │  │ │ S3 API  │ │
   │ │ Handler │ │  │ │ Handler │ │  │ │ Handler │ │
   │ └────┬────┘ │  │ └────┬────┘ │  │ └────┬────┘ │
   │      │      │  │      │      │  │      │      │
   │ ┌────▼────┐ │  │ ┌────▼────┐ │  │ ┌────▼────┐ │
   │ │ Crypto  │ │  │ │ Crypto  │ │  │ │ Crypto  │ │
   │ │ Layer   │ │  │ │ Layer   │ │  │ │ Layer   │ │
   │ │(Kyber+  │ │  │ │(Kyber+  │ │  │ │(Kyber+  │ │
   │ │Dilithium│ │  │ │Dilithium│ │  │ │Dilithium│ │
   │ └────┬────┘ │  │ └────┬────┘ │  │ └────┬────┘ │
   └──────┼──────┘  └──────┼──────┘  └──────┼──────┘
          │                │                │
          └────────────────┴────────────────┘
                           │
                    ┌──────▼──────┐
                    │Ceph Cluster │
                    │(Encrypted   │
                    │ Backend)    │
                    └─────────────┘

Trust Boundaries

Untrusted:

• Customer applications and SDKs
• Public internet
• Cloudflare edge (terminates TLS)

Semi-Trusted:

• RustFS gateways (handle encryption/decryption)

Trusted:

• Ceph storage backend (sees only encrypted data)
• Key management service (HSM-backed)

Cryptographic Architecture

RustFS uses a hybrid post-quantum cryptosystem:

┌─────────────────────────────────────────────────────────────┐
│              Post-Quantum Encryption Flow                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Key Encapsulation (Kyber-768)                          │
│     ├── Generates ephemeral key pair                        │
│     ├── Encapsulates shared secret                          │
│     └── Provides ciphertext for recipient                   │
│                                                             │
│  2. Authentication (Dilithium-3)                           │
│     ├── Signs the Kyber ciphertext                          │
│     └── Prevents tampering with key exchange                │
│                                                             │
│  3. Symmetric Encryption (AES-256-GCM)                     │
│     ├── Uses shared secret from Kyber                       │
│     ├── Encrypts object data                                │
│     └── Provides authenticated encryption                   │
│                                                             │
│  4. Storage                                                │
│     ├── Encrypted object stored in Ceph                     │
│     ├── Metadata (size, checksum) in cleartext              │
│     └── Encryption keys never persisted                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Key properties:

• Kyber-768: NIST Level 3 post-quantum KEM
• Dilithium-3: NIST Level 3 post-quantum signatures
• AES-256-GCM: 256-bit authenticated encryption
• Unique keys per object
• Keys derived from customer master key + object salt

---

Internal Threat Overview

Authentication

RustFS supports multiple authentication methods:

1. Access Keys (HMAC)

┌─────────────────────────────────────────────────────────────┐
│                  Request Signing Flow                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Client constructs canonical request                     │
│     ├── HTTP method                                         │
│     ├── URI path                                            │
│     ├── Query parameters (sorted)                           │
│     ├── Headers (signed headers)                            │
│     └── Hashed payload (SHA-256)                            │
│                                                             │
│  2. String to sign                                          │
│     ├── Algorithm (AWS4-HMAC-SHA256)                        │
│     ├── Timestamp                                           │
│     ├── Scope (date/region/service)                         │
│     └── Hashed canonical request                            │
│                                                             │
│  3. Signature                                               │
│     ├── HMAC-SHA256 with secret key                         │
│     └── Included in Authorization header                    │
│                                                             │
│  4. Server verification                                     │
│     ├── Reconstructs string to sign                         │
│     ├── Computes expected signature                         │
│     └── Compares (constant-time)                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Security properties:

• No secret transmitted over network
• Request integrity protected
• Replay protection via timestamp (5-minute window)
• Scope limits blast radius of leaked credentials

2. Presigned URLs

Temporary access grants:

# Generate presigned URL (valid for 1 hour)
aws s3 presign s3://my-bucket/file.txt --expires-in 3600

# Result: https://s3.tasmanian.cloud/my-bucket/file.txt?
#   X-Amz-Algorithm=AWS4-HMAC-SHA256
#   &X-Amz-Credential=...
#   &X-Amz-Date=...
#   &X-Amz-Expires=3600
#   &X-Amz-SignedHeaders=host
#   &X-Amz-Signature=...

Authorization (IAM Policies)

Bucket policies control access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789:user/developer"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/uploads/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.40.0/22"
        },
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    }
  ]
}

Policy evaluation:

1. Default deny
2. Evaluate all applicable policies
3. Explicit deny overrides any allow
4. No explicit allow → deny

Data Integrity

Multiple layers of integrity protection:

Replication and Durability

┌─────────────────────────────────────────────────────────────┐
│              Ceph Replication Architecture                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Object uploaded to RustFS Gateway                          │
│            │                                                │
│            ▼                                                │
│  ┌─────────────────────────────────────────────┐           │
│  │  Erasure Coding (4+2) or 3x Replication     │           │
│  │                                             │           │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐       │           │
│  │  │ OSD 1   │ │ OSD 2   │ │ OSD 3   │       │           │
│  │  │ (Rack 1)│ │ (Rack 2)│ │ (Rack 3)│       │           │
│  │  └─────────┘ └─────────┘ └─────────┘       │           │
│  │                                             │           │
│  │  ┌─────────┐ ┌─────────┐                    │           │
│  │  │ OSD 4   │ │ OSD 5   │  (Erasure coding) │           │
│  │  │ (Rack 1)│ │ (Rack 2)│                   │           │
│  │  └─────────┘ └─────────┘                    │           │
│  └─────────────────────────────────────────────┘           │
│                                                             │
│  Durability: 99.999999999% (11 nines)                      │
│  Availability: 99.99%                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Attack Scenarios and Mitigations

Scenario 1: Stolen Storage Node

Attack: Attacker physically steals a Ceph OSD node.

Mitigations:

• All data encrypted at rest
• Keys not stored on OSD nodes (derived on gateways)
• Theft of single node insufficient (need threshold for erasure coding)

Scenario 2: Network Eavesdropping

Attack: Attacker intercepts traffic between customer and RustFS.

Mitigations:

• TLS 1.3 for all API traffic
• Certificate pinning available
• No cleartext data transmission

Scenario 3: Replay Attack

Attack: Attacker captures signed request and replays it.

Mitigations:

• Timestamp in signature (5-minute validity)
• Nonce for idempotent operations
• Presigned URL expiration

Scenario 4: Bucket Enumeration

Attack: Attacker tries to discover bucket names.

Mitigations:

• No ListBuckets for unauthenticated users
• Rate limiting on authentication attempts
• Random bucket names recommended

---

Security Controls Summary

---

Standards Alignment

We are not certified against the standards below. The table maps relevant controls to our RustFS implementation.

---

Related Documentation

• O2S Threat Model
• VPS Threat Model
• TWN Stack Security
• RustFS Documentation