# Kotsch.Tech – Lizenz- & Key-Management (Konzept)

Zentrales Aktivierungs-/Lizenzsystem für **alle** Windows-Apps, gesteuert über die
bestehende Website (Server + Admin + Shop). Stand: Konzept, vor Implementierung.

## Festgelegte Eckpunkte
- **Lizenzmodell:** Einmalkauf, **dauerhaft – lebenslang alle Versionen** (keine Versionsgrenze).
- **Geräte pro Key:** **bis zu 3**, Slot-Freigabe per Self-Service/Admin.
- **Offline:** **großzügig** – nach Aktivierung lange offline nutzbar; Sperren/Limit greifen beim nächsten Online-Kontakt.
- **Verkauf:** **je App ein eigener Key** (kein Konto/Bundle vorerst).
- **Testphase:** **keine** – App startet nur mit gültigem Key.
- **Bezahlung:** **PayPal + Stripe** parallel.

## Sicherheits-Grundprinzip
Online-Aktivierung + **asymmetrisch signierte Lizenz-Tokens** + Gerätebindung.
- Der **Key** ist nur ein Anspruchscode (server-seitig nachgeschlagen), keine Sicherheitsgrenze.
- Aktivierung gibt ein **mit Server-Privatkey signiertes Token** zurück; die App trägt nur den **Public-Key** und prüft die Signatur offline → Token ist **nicht fälschbar** ohne den Privatkey.
- **Lease 365 Tage**, stille Erneuerung bei Online-Kontakt → Sperren & 3-Geräte-Limit wirken, ohne ständiges „Phone-home".
- Realität: Clientseitiger Schutz ist nie 100 % cracksicher; dieses Modell stoppt zuverlässig Weitergabe/Kopieren/Nutzung ohne Kauf und erlaubt Personenbindung + Sperren.

## Komponente A – Apps (gemeinsames SDK)
Wiederverwendbare .NET-Library `Kotsch.Licensing`, von jeder WinUI-App eingebunden.
Pro App nur Konfiguration: `appId`, eingebetteter Public-Key, Server-URL, Feature-Stufen.
- Erststart → Aktivierungs-Screen (Key) → `POST /activate` mit Geräte-Fingerprint.
- Token lokal via **Windows DPAPI** verschlüsselt (an Gerät/Benutzer gebunden).
- Jeder Start: Signatur + `appId` + `dev` + Lease prüfen → gültig: starten; abgelaufen: stille Erneuerung; offline: lange Karenz.
- Hartes **Gate**: Hauptfenster nur bei gültiger Lizenz (keine Trial-Umgehung).
- Geräte-Fingerprint = SHA-256 aus stabilen Merkmalen (u. a. Windows `MachineGuid`).

**Token-Claims (Beispiel):**
```
{ "sub":"cust_…", "lic":"lic_…", "app":"convertly", "tier":"pro",
  "dev":"<fingerprint-hash>", "iat":…, "exp":<iat+365d> }   // keine Versionsgrenze
```

## Komponente B – Server + Admin
**Stack:** Node.js + Express, PostgreSQL (SQLite zum Start), Deploy via PM2/Nginx/certbot.
Token-Signatur via `jose` (EdDSA), App-Verifikation built-in mit RSA-PSS möglich.

**Datenmodell (Kern):**
- `customers`: id, email, name
- `licenses`: id, **key_hash**, customerId (Pflicht-FK → „immer einer Person"), appId, tier, status (active/revoked), maxDevices=3, herkunft (shop/admin), orderId
- `devices`: licenseId, fingerprint_hash, name, firstSeen, lastSeen
- `events`: lückenloses Audit-Log (Aktivierung, Erneuerung, Sperre, Ausgabe)

**API (nur HTTPS):**
- `POST /activate` {key, appId, fingerprint, deviceName} → prüft, bindet Gerät (max 3), gibt signiertes Token
- `POST /refresh` {token} → erneuert Lease, prüft Sperre
- `POST /deactivate` {token} → Gerät-Slot freigeben
- Rate-Limiting / Brute-Force-Schutz auf Key-Eingabe

**Keys:** kryptografisch zufällig, Format `APP-XXXXX-XXXXX-XXXXX` (Crockford-Base32). DB speichert **nur den Hash**; Klartext nur bei Erstellung/Mailversand.

**Admin-Bereich** (im bestehenden, geschützten Admin; **2FA empfohlen**):
- Kunde anlegen, Lizenz ausgeben (App/Stufe/Geräteanzahl/Person), Mail senden
- Suchen, Geräte ansehen, **sperren**, Gerätebindung zurücksetzen
- Audit-Log einsehen
- **Privatkey** in Secret-Datei/ENV außerhalb Web-Root, nie im Git; Key-Rotation (App akzeptiert mehrere Public-Keys).

## Komponente C – Shop (PayPal + Stripe)
- Checkout → **verifizierter Webhook** (PayPal `PAYMENT.CAPTURE.COMPLETED`, Stripe `checkout.session.completed`) → gemeinsame, **idempotente** Fulfillment-Funktion (pro Order-ID) → Kunde anlegen/finden → **Key erzeugen + gehasht speichern** → **E-Mail** mit Key + Download-Link + Vorab-Anleitung.
- Auslieferung **nur** bei server-verifizierter Zahlung (nie Browser-Erfolgsseite).
- **Refund/Chargeback-Webhook → Key automatisch sperren.**
- Mail über Postmark/SendGrid/SES.
- Optional später: Self-Service-Portal („meine Lizenzen", Mail erneut, Geräte verwalten).

**DE/EU-Pflichten (einplanen):**
- Widerrufs-Checkbox für digitale Güter (sofortige Lieferung, Verzicht aufs Widerrufsrecht).
- Impressum + Datenschutzerklärung.

## Sicherheits-Checkliste
TLS überall · Keys nur gehasht in DB · Token asymmetrisch signiert · DPAPI-Speicherung in der App · Rate-Limiting · Audit-Log · 2FA im Admin · Webhook-Signaturen verifizieren · Idempotenz bei Fulfillment · Secrets außerhalb Git · Key-Rotation vorgesehen.

## Umsetzung in Phasen
1. **Lizenz-Server-Kern** (DB, `/activate` + `/refresh` + `/deactivate`, Signierung) + **App-SDK** + Aktivierungs-Screen (zuerst in Convertly).
2. **Admin-Bereich** (ausgeben/sperren/zuordnen, Audit, 2FA).
3. **Shop** (PayPal + Stripe Webhooks, Mail-Automatik, Anleitung, Widerruf/Impressum).
4. **Härtung** (Rate-Limits, Obfuskierung, Self-Service-Portal).