Cryptography & Data Protection
Streamdiver operates a sovereign media platform with AI-powered content processing — exclusively on European infrastructure in Austria, Germany, and Finland. No US cloud services are used; there is no exposure to the CLOUD Act.
This document describes the cryptographic protection of data across its entire lifecycle: from capture in the browser, through encrypted transmission and storage, to AI processing. It is intended for security officers, data protection officers, and technical decision-makers who require a thorough assessment of data security.
| Document ID | TC-CDP-001 |
| Version | 1.4 |
| Date | 2026-10-08 |
| Scope | Streamdiver Platform |
| Applicable Law | GDPR (EU), öDSG (AT); compatible with BDSG (DE) and FADP/nDSG (CH) |
| Related Documents | TC-LLM-001 — LLM Infrastructure and Data Protection |
Cryptographic Protection Profile:
- End-to-end transport encryption (TLS 1.2/1.3) on all external communication paths
- Mutual authentication and encryption of internal services via service mesh (mTLS) with automatic certificate rotation every 24 hours
- Multi-layered network encryption: TLS (external) → mTLS (service mesh) → WireGuard (CNI-level on AI cluster; cross-cluster tunnels via Tailscale)
- AES-256 volume encryption for all managed databases with automatic key rotation
- AES-256 server-side encryption for all media content in object storage
- Encrypted database backups (AES-256-CTR with RSA-3072 key wrapping), plus an AES-256 encrypted archive copy of the database with a second, independent European provider; database backups are retained for 3 months
- Centralized, automated secrets management with audit trail
- Self-hosted AI services and LLM inference — no data outflow to third parties
- 100% European infrastructure (Exoscale AT/CH, Hetzner DE, Verda FI) with no CLOUD Act exposure
The measures described in this document are managed and continuously improved within the Streamdiver Information Security Management System (ISMS), aligned with ISO/IEC 27001:2022.
1. Data Flow & Browser Security
1.1 Architecture Principle
The Streamdiver platform processes media content (video, audio, documents) through a cloud-based pipeline. The end user's browser serves exclusively as a control interface and playback client — not as a storage or processing location for media data.
1.2 Upload Flow (Browser → Server)
The upload process works as follows:
- The user selects a file in the management interface.
- The file is transmitted to the backend API via HTTPS (TLS 1.2/1.3).
- The API stores the file directly in object storage (S3-compatible, TLS-encrypted).
- Metadata is recorded in the encrypted application database.
During upload, the browser holds the file reference exclusively in volatile memory (RAM). No media data is stored in LocalStorage, IndexedDB, or SessionStorage. After the upload completes or the session is terminated, no file fragments remain in the browser.
1.3 Playback Flow (Streaming)
Media playback uses HLS (HTTP Live Streaming) with all traffic encrypted via TLS 1.2/1.3. Content access is governed by the platform's channel-based authorization model — only assets assigned to channels the requesting client is authorized for are served.
- The player requests an HLS manifest via HTTPS.
- The origin server validates the request, generates HLS segments on-demand from source files in object storage, and delivers them via HTTPS.
- The player holds only the current and next segments in a volatile RAM buffer — no media data is written to disk or persistent browser storage.
1.4 Browser Storage & Caching
The Streamdiver player is designed to leave no persistent trace on the end user's device:
| Control | Details |
|---|---|
| No application-level storage | No LocalStorage, IndexedDB, SessionStorage, or cookies are used |
| RAM-only buffering | Media segments exist only in volatile memory during playback |
Cache-Control headers | Short max-age values minimize the window for browser HTTP cache retention |
| TLS-only delivery | All content is bound to the encrypted HTTPS session |
The browser's built-in HTTP cache may briefly retain HLS segments as part of standard protocol behavior. This is transient and controlled by the Cache-Control headers described above.
Implementation Status — Data Flow & Browser Security
Measure Status No persistent media storage in browser Implemented TLS-protected upload and streaming Implemented Cache control via HTTP headers Implemented Channel-based access control Implemented
2. Data in Transit
2.1 External Communication (Client ↔ Server)
All communication between end devices and the Streamdiver platform is transport-encrypted.
| Parameter | Value |
|---|---|
| Protocol | TLS 1.2 / TLS 1.3 |
| TLS Termination | API Gateway (Envoy-based) |
| Cipher Suites | Envoy proxy defaults: ECDHE key exchange with AES-GCM and ChaCha20-Poly1305; legacy ciphers (RC4, 3DES, CBC) are not supported by the proxy |
| Certificates | Automatically managed (Let's Encrypt) with automatic renewal |
| HSTS | Enabled on all public endpoints |
2.2 Internal Communication (Service ↔ Service)
Service-to-service traffic within each Kubernetes cluster is secured by a service mesh. The scope of mTLS enforcement varies by cluster:
| Cluster | mTLS Mode | Scope |
|---|---|---|
| AI Processing Cluster (Hetzner, DE) | mTLS STRICT | All services — plaintext connections are rejected |
| Application Cluster (Exoscale, AT) | mTLS PERMISSIVE | mTLS enabled and used for all mesh-enrolled services; enforcement is being tightened to STRICT |
Service mesh properties (both clusters):
| Parameter | Value |
|---|---|
| Identities | Cryptographic workload identities (SPIFFE-compatible) |
| Certificate Rotation | Automatic every 24 hours |
| Authorization | Policy-based access control per service |
Each mesh-enrolled service receives its own workload certificate. Cross-cluster communication (e.g., application cluster to AI processing cluster) is secured via WireGuard tunnels (see Section 2.3 and 2.4), not via the service mesh.
2.3 Network Layer (CNI Encryption)
On the AI processing cluster (Hetzner, Germany), the CNI plugin provides an additional encryption layer beneath the service mesh:
| Parameter | Value |
|---|---|
| Technology | WireGuard (Flannel backend) |
| Encryption | ChaCha20-Poly1305 |
| Key Exchange | Curve25519 |
| Coverage | All inter-node traffic on the AI processing cluster — including system components outside the service mesh |
On this cluster, AI workloads benefit from a triple encryption layer: TLS (external) → mTLS (service mesh) → WireGuard (network).
The application cluster (Exoscale, Austria) is secured by the service mesh (mTLS) for all application traffic, complemented by cloud-native network security groups that restrict infrastructure-level communication to authorized cluster members only.
2.4 AI Access (Egress Encryption)
Access to the self-hosted LLM inference servers uses end-to-end encrypted WireGuard tunnels. The LLM servers are not publicly accessible — all traffic flows exclusively through the encrypted overlay network with identity-based access control.
2.5 Database Connections
| Connection | Encryption | Details |
|---|---|---|
| API → Database | TLS (mandatory) | Plaintext connections are disabled; optional TLS client certificates available |
| Database Replication | VPN / IPSec | Replication traffic between nodes encrypted |
| API → Object Storage | TLS 1.2+ | S3 API access via HTTPS |
| API → Cache | TLS (mandatory) | Managed service standard |
| API → Search Index | HTTPS / mTLS | Encrypted with mutual authentication within service mesh |
| Service → Message Broker | mTLS | Within service mesh |
Implementation Status — Data in Transit
Measure Status TLS 1.2/1.3 for external communication Implemented mTLS STRICT for AI processing cluster Implemented mTLS PERMISSIVE for application cluster (STRICT rollout in progress) Implemented WireGuard encryption at network layer Implemented WireGuard for LLM access Implemented Mandatory TLS for database connections Implemented
3. Data at Rest
By default, data at rest is held by Exoscale and Hetzner, both certified under ISO/IEC 27001 and attested under BSI C5. Certificates and links to verify them: Infrastructure & Sub-Processors.
3.1 Application Database
The primary application database is operated as a managed service with a European cloud provider (Exoscale, Austria/Switzerland) and provides full encryption at rest.
Encryption at Rest (Volume-Level):
| Parameter | Value |
|---|---|
| Level | Volume-Level (Full-Disk Encryption) |
| Method | LUKS2 |
| Cipher | aes-xts-plain64:sha256 |
| Key Length | 512 bit |
| Key Generation | Randomly generated, ephemeral key per instance and volume |
| Key Rotation | Automatic — keys are permanently destroyed on instance termination, natural rotation on upgrades |
| Transparency | Fully transparent — no client-side configuration required |
Access Protection:
| Measure | Details |
|---|---|
| IP-based firewall | Access only from authorized network ranges |
| TLS client certificates | Optionally available (in addition to username/password) |
| High availability | Primary + standby node with automatic failover |
3.2 Database Backups
Database backups are kept in two independent layers: provider backups at the database provider, and an encrypted archive copy of the database with a second, independent European provider. Media content is not part of this archive. Database backups are retained for 3 months.
Provider backups (database provider, Austria). Backup encryption is multi-layered and fully separated from database access:
| Parameter | Value |
|---|---|
| File Encryption | AES-256-CTR (per file) |
| Integrity Check | HMAC-SHA256 |
| Key Wrapping | Per-service RSA-3072 key pair |
| Frequency | Daily automatic backups |
| Point-in-Time Recovery | Supported via transaction logs |
| Restoration | Database forking (within region or cross-region) |
Database archive copy (Hetzner, Germany). Protects against the loss of the database provider as a whole:
| Parameter | Value |
|---|---|
| Encryption | AES-256, applied before transfer; transferred over SSH |
| Location | Hetzner, Germany (ISO/IEC 27001, BSI C5): an independent European provider in a different country from the database |
| Retention | 3 months |
Backup keys are managed separately from backup data and are not accessible through regular database access.
3.3 Object Storage (Media Content)
All media content (video, audio, images, documents) is stored in S3-compatible object storage, with a separate storage area for each customer. By default, this is managed object storage from Exoscale in a European data center in Vienna, Austria, encrypted at rest. On request, a customer's media can be stored in any other location of their choice, including storage operated by the customer.
| Parameter | Value |
|---|---|
| Location | Vienna, Austria by default; any other location on customer request, including the customer's own storage |
| Storage | S3-compatible object storage; by default operated by Exoscale (ISO/IEC 27001, BSI C5) |
| Tenant Separation | One bucket per customer |
| Encryption at Rest | AES-256 server-side encryption, enabled by default |
| Encryption in Transit | TLS 1.2+ |
| Replication | Default storage: three copies on separate high-availability nodes, all in the same location |
Protection at rest: In the default storage, media is encrypted with AES-256 when it is written. Storage is private, with no public or anonymous access. Only the Streamdiver platform accesses it, over TLS 1.2+ and with centrally managed credentials. For each upload or download, the platform gives the user short-lived access to a single file of their own tenant.
3.4 Tenant Isolation (Multi-Tenancy)
Data separation between customers is enforced at all data layers:
| Layer | Isolation Mechanism |
|---|---|
| Object Storage | Dedicated, private storage per customer; users receive only short-lived access to single files of their own tenant |
| Database | Logical separation at application level; every data access is bound to the tenant ID |
| Search Index | Logical separation by tenant ID; all media identifiers are globally unique |
| Cache | Transient data with tenant prefix; no persistent customer data in cache |
A customer never has access to another customer's data. Tenant separation is enforced at the application level and supplemented by network isolation and access policies at the infrastructure level.
3.5 Protection of Sensitive Data in Logs
The architecture ensures that no sensitive user data is written to system logs:
- The AI pipeline writes structured metadata to the application database and search index — not to log streams.
- Transcripts, names, and other personal data are persisted exclusively in the designated, encrypted data stores.
- API logs contain request metadata (method, path, status) but no request/response bodies.
Implementation Status — Data at Rest
Measure Status Database volume encryption (LUKS2 AES-256) Implemented Backup encryption (AES-256-CTR, RSA-3072) Implemented Encrypted database archive copy at a second European provider (3-month retention) Implemented Cache volume encryption (LUKS2 AES-256) Implemented Object Storage encryption at rest (AES-256 server-side) Implemented Object Storage: private storage, short-lived per-file access Implemented Tenant isolation at all data layers Implemented
4. Key Management
4.1 Key Type Overview
| Key Type | Management | Rotation |
|---|---|---|
| TLS Certificates (external) | Automatic (Let's Encrypt + certificate manager) | Before expiry (automatic) |
| mTLS Certificates (service mesh) | Automatic (integrated CA) | Every 24 hours |
| Database Volume Encryption | Fully managed by service provider | Ephemeral — destroyed on instance termination |
| Backup Encryption (provider backups) | Fully managed by service provider | Per-service RSA-3072 key pair |
| Object Storage Encryption | Fully managed by service provider (server-side) | Managed by service provider |
| WireGuard Keys (network) | Automatic | On node restart |
| WireGuard Keys (LLM access) | Automatic | Automatically rotated |
| Application Secrets | Central secrets management → automatic cluster synchronization | Propagated automatically on change |
4.2 TLS Certificates
External Certificates:
- Automatically issued and renewed (Let's Encrypt)
- Managed via a dedicated certificate manager in the container orchestration
- No manual intervention required
Service Mesh Certificates (mTLS):
- Integrated certificate authority with automatic certificate issuance
- SPIFFE-compatible X.509 certificates
- Lifetime: 24 hours with automatic rotation
- Automatic distribution to all services
4.3 Database Keys
Storage Location: The encryption keys for the application database are managed exclusively within the infrastructure of the European managed service provider (Exoscale / Aiven). No external KMS service or HSM is used — the keys remain entirely within the provider infrastructure in Austria/Switzerland.
Key Lifecycle:
- Generation: Each instance and volume receives a unique, randomly generated ephemeral key
- Rotation: Automatic on upgrades — keys are permanently destroyed on instance termination and replaced with new ones
- Access: No access to encryption keys by Streamdiver personnel — neither by administrators nor by support
Backup Keys (provider backups):
- Per-service RSA-3072 key pair for wrapping AES-256-CTR file keys
- Fully managed by the provider; separated from database access credentials
- Backup keys are also not accessible to Streamdiver personnel
4.4 Secrets Management
All application secrets (database credentials, API keys, service credentials) are centrally managed in a dedicated secrets manager and automatically synchronized into production environments via a Kubernetes operator.
| Property | Details |
|---|---|
| Central Management | All secrets are stored in a dedicated, encrypted vault |
| No Secrets in Source Code | Secrets are stored exclusively as references — actual values remain in the vault |
| Automatic Synchronization | Changes are automatically propagated to the production environment |
| Automatic Restart | Services are automatically updated on secret changes |
| Environment Separation | Separate vaults for production, test, and development |
| Access Control | Role-based, MFA-protected |
| Audit Trail | Complete logging of all accesses and changes |
4.5 Access Control for Keys and Infrastructure
Who has technical access to decryption keys?
| Key Type | Access by Streamdiver | Details |
|---|---|---|
| Database Volume Encryption | No access | Keys are fully managed by the provider; neither visible nor extractable by Streamdiver personnel |
| Backup Keys (provider backups) | No access | Provider-managed; separated from database access |
| TLS and mTLS Certificates | No manual access | Automatically generated and rotated; private keys remain in the cluster infrastructure |
| Application Secrets | Restricted — DevOps role only | Access to the secrets vault requires MFA and is restricted to the DevOps role; all accesses are logged |
Infrastructure Security:
| Layer | Mechanism |
|---|---|
| Network | VPN-protected access — no direct internet access to management interfaces |
| Authentication | Central identity provider (OAuth 2.0 + OpenID Connect), MFA enforced |
| Authorization | Role-based access control (RBAC) |
| Database Administration | IP-based access restriction + credentials |
| Secrets Management | Separated permissions; applications receive only the secrets intended for them |
Emergency Access (Break-Glass):
Emergency access to production systems is subject to elevated requirements: access requires VPN, MFA, and an authorized role. All administrative accesses to infrastructure and secrets are fully logged via the secrets manager audit trail and provider logs. The formal break-glass procedure is documented and maintained within the ISMS.
Implementation Status — Key Management
Measure Status Automated TLS certificate management Implemented mTLS certificate rotation (24 h) Implemented Database key management (provider-managed) Implemented Backup key management for provider backups (provider-managed) Implemented Central secrets management with audit trail Implemented Role-based access control (RBAC + MFA) Implemented Logging of all administrative accesses Implemented
5. Cryptography During Processing (Data in Use)
5.1 Processing Architecture
AI processing is performed in a three-stage pipeline on dedicated GPU servers in European data centers:
| Stage | Task | Examples |
|---|---|---|
| I — Extraction | Raw data → structured data | Speech recognition (ASR), speaker diarization, keyframe extraction, OCR |
| II — Enrichment | Structured data → semantics | Entity extraction, summarization, text embedding, question generation |
| III — Representation | Semantics → search index | Indexing (full-text + vector search) |
The processing infrastructure is network-isolated and secured by mTLS and WireGuard encryption at the network layer.
5.2 Decryption Window
Media data must be available in plaintext for AI processing. The plaintext exposure window is strictly limited:
Where is data in plaintext?
Exclusively in the volatile memory (RAM) of the GPU workers during active processing. There is no intermediate storage on local disks.
5.3 Secure Deletion
| Measure | Details |
|---|---|
| Stateless Architecture | No state remains on the server after job completion; processing data is held in RAM only and released when the request completes |
| No Local Disk Access | No persistent volumes for intermediate results |
| Network Isolation | AI workloads run in a dedicated, isolated network segment with their own access policies |
5.4 LLM Inference
LLM-based processing (RAG, summarization, question generation) is performed on self-hosted servers in European data centers:
| Property | Details |
|---|---|
| Location | Dedicated servers in European data centers (Exoscale AT/CH, Hetzner DE, Verda FI — all ISO 27001 certified) |
| Access | Exclusively via encrypted WireGuard tunnel (private overlay network) |
| Inference Framework | vLLM with OpenAI-compatible API (open source) |
| Models | State-of-the-art open-source models — self-hosted, no third-party API usage |
| Data Outflow | None — no data transfer to OpenAI, Google, Anthropic, or any other external AI service |
| Training | No customer data is used for model training; open-source models are used as-is |
| Plaintext in RAM | During inference, prompts and context data reside in the LLM server's RAM |
A detailed description of the LLM infrastructure, including hosting location, data flow, and CLOUD Act assessment, is documented in LLM Infrastructure and Data Protection (TC-LLM-001).
Implementation Status — Cryptography During Processing
Measure Status Plaintext exclusively in RAM Implemented Stateless AI services without local disk access Implemented Self-hosted LLM inference (no data outflow) Implemented Network isolation (mTLS + WireGuard + dedicated segment) Implemented
6. Data Flow Diagram
The following diagram shows the trust zones of the Streamdiver platform, the encryption states at zone boundaries, and the areas where data is processed in plaintext.
6.1 Data Flow with Encryption States
6.2 Encryption by Data State
| Data State | Protection | Details |
|---|---|---|
| In the browser | TLS 1.2/1.3 | No media stored locally; data held in RAM only during upload/playback |
| In transit (external) | TLS 1.2/1.3 | All client-server communication encrypted |
| In transit (internal) | mTLS + WireGuard | Service-to-service encryption with mutual authentication |
| At rest (databases) | AES-256 | Volume-level encryption with automatic key rotation |
| At rest (media files) | AES-256 | Server-side encryption by default; private storage; short-lived per-file access over TLS |
| During AI processing | Plaintext in RAM | Data decrypted in volatile memory only; no disk storage; released when processing completes |
| During LLM inference | Plaintext in RAM | Self-hosted, isolated via WireGuard tunnel; no data sent to external AI providers |
6.3 Trust Zone Boundaries
| Zone | Encryption Boundary | Plaintext Exposure |
|---|---|---|
| Browser / Client | TLS 1.2/1.3 at zone edge | Playback in player (RAM only) |
| Streamdiver Cloud | mTLS between services, TLS to storage | No — data encrypted at rest and in transit |
| AI Processing | WireGuard + mTLS | Yes — RAM during processing (ephemeral) |
| LLM Inference | WireGuard (end-to-end) | Yes — RAM during inference (ephemeral) |
7. Base Technology & CLOUD Act Independence
7.1 Technology Stack
The Streamdiver platform is built exclusively on open-source software and European-managed services. No Microsoft products and no proprietary US cloud software are used in the data path.
| Category | Product | License | Origin |
|---|---|---|---|
| Container Orchestration | Kubernetes (Exoscale SKS, K3s) | Open Source (Apache 2.0) | CNCF; managed by Exoscale (Switzerland) or self-operated |
| Service Mesh | Istio | Open Source (Apache 2.0) | CNCF / Istio Steering Committee |
| Relational Database | PostgreSQL | Open Source (PostgreSQL License) | PostgreSQL Global Development Group |
| Object Storage | S3-compatible object storage (default: Exoscale) | Managed service | By default data is stored in Austria (Exoscale SOS AT-VIE); other locations are possible |
| Search Index / Vector DB | Elasticsearch | Open Source (Elastic License 2.0) | Elastic N.V. (Netherlands); self-operated |
| Cache | Redis | Open Source (BSD) | Managed by Exoscale DBaaS (Switzerland) |
| Message Broker | RabbitMQ | Open Source (MPL 2.0) | Self-operated on Kubernetes |
| Identity Provider | Keycloak | Open Source (Apache 2.0) | Self-hosted on Kubernetes |
| Web Server / Reverse Proxy | NGINX | Open Source (BSD) | Self-operated |
| Web Analytics | Matomo | Open Source (GPL v3) | Self-hosted on dedicated VM |
| Network Encryption | WireGuard | Open Source (GPL v2) | Integrated at CNI layer |
| Firewall | Open-source firewall | Open Source (Apache 2.0) | Self-operated |
| LLM Inference | vLLM (OpenAI-compatible API) | Open Source (Apache 2.0) | Self-hosted; details in separate document LLM Infrastructure and Data Protection |
7.2 CLOUD Act Assessment at Technology Level
The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) authorizes US authorities to compel US companies to disclose data — even when stored outside the United States. However, this authority applies exclusively to service relationships with US companies, not to the use of open-source software.
Streamdiver Assessment:
| Layer | CLOUD Act Exposure | Rationale |
|---|---|---|
| Company | None | Streamdiver FlexCo is an Austrian company with no US ownership |
| Hosting Providers | None | Exoscale (Switzerland), Hetzner (Germany), Verda (Finland) — exclusively European providers |
| Database | None | PostgreSQL (open source), operated by Exoscale/Aiven (Switzerland/Finland, EU) |
| Software Stack | None | Exclusively proprietary Streamdiver software or open-source software with no service relationship to US companies |
| LLM Inference | None | Self-hosted open-source models on European infrastructure; no data flow to US providers |
No Microsoft Products: The entire platform — from the operating system through the databases to AI processing — runs without Microsoft products (no Windows, no Azure, no SQL Server, no Microsoft 365). There is no service or licensing relationship with Microsoft whatsoever.
Appendix
References
| Source | URL |
|---|---|
| Aiven Cloud Security | https://github.com/aiven/aiven-docs/blob/main/docs/platform/concepts/cloud-security.md |
| Exoscale DBaaS Data Protection | https://www.exoscale.com/blog/dbaas-general-availability-and-data-protection/#security |
| Exoscale Object Storage | https://community.exoscale.com/product/storage/object-storage/overview/ |
| Exoscale Shared Responsibility Model | https://community.exoscale.com/platform/compliance/shared-responsability-model/ |
| Istio PeerAuthentication (mTLS) | https://istio.io/latest/docs/reference/config/security/peer_authentication/ |
| SPIFFE Identity and Verifiable Identity Document | https://spiffe.io/docs/latest/spiffe-specs/spiffe-id/ |
| K3s Flannel WireGuard Backend | https://docs.k3s.io/networking/basic-network-options |