====== AGLX – Sicherheitsaspekte und Verschlüsselung ======

Sicherheit ist ein zentrales Designziel des AGLX-Protokolls.  
Da Agenten eigenständig handeln, Entscheidungen treffen und miteinander kommunizieren, müssen **Authentizität, Integrität und Vertraulichkeit** jederzeit gewährleistet sein.  
AGLX setzt dafür auf eine Kombination aus Verschlüsselung, digitaler Signierung, Vertrauenszonen und kontextabhängiger Zugriffskontrolle.
===== Grundprinzip =====

Sicherheit in AGLX wird nicht zentral verwaltet, sondern **dezentral durch Vertrauen und kryptografische Verfahren** gewährleistet.  
Jeder Agent ist selbst verantwortlich für den Schutz seiner Kommunikation und Identität.

^ Prinzip ^ Beschreibung ^
| **Ende-zu-Ende-Verschlüsselung** | Jede TCP-Kommunikation zwischen Agenten kann verschlüsselt werden (TLS oder DTLS). |
| **Signierte Nachrichten** | Jede Nachricht kann digital signiert werden, um Manipulationen zu verhindern. |
| **Vertrauenszonen (Trust Zones)** | Agenten in derselben Zone teilen Schlüssel oder Zertifikate. |
| **Authentifizierung** | Agenten authentifizieren sich gegenseitig über Signaturen, Tokens oder Zertifikate. |
| **Minimal Exposure** | Agenten veröffentlichen nur die notwendigsten Daten in der Registry. |

===== Authentifizierung und Identität =====

Jeder Agent besitzt eine eindeutige digitale Identität, die in einer **Agenten-ID** und einem **Signaturschlüssel** besteht.  
Diese Identität wird beim Start erzeugt und optional durch ein Zertifikat einer Registry bestätigt.

**Beispiel:** Registrierung mit signierter Identität

<code diff>
AGLX/1.0 TCP
FROM: agent://node17.local
TO: registry://global.aglx.net
TYPE: registry.update
CONTENT-TYPE: application/json

{
    "agent_name": "Node17",
    "agent_type": "worker",
    "public_key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
    "signature": "hmac-sha256:3f8d1ab2...",
    "capabilities": ["data.analyze", "task.execute"],
    "status": "READY"
}
</code>

Die Registry prüft die Signatur gegen den öffentlichen Schlüssel und gibt eine signierte Bestätigung zurück.

<code diff>
AGLX/1.0 TCP
FROM: registry://global.aglx.net
TO: agent://node17.local
TYPE: registry.ack
SIGNATURE: rsa-sha256:72c1b9d0...
STATUS: 200 OK
</code>

===== Transportverschlüsselung =====

AGLX unterstützt mehrere Transportmodi, die abhängig von Netztyp und Sicherheitsniveau gewählt werden können.

^ Modus ^ Beschreibung ^ Einsatzgebiet ^
| **TCP (unverschlüsselt)** | Nur für geschlossene, interne LANs. Schnell, aber unsicher über WAN. | Testnetze, lokale Simulationen |
| **TCP + TLS** | Standardmodus für produktive Umgebungen. Schützt Daten gegen Abhören und Manipulation. | Public WAN, Rechenzentren |
| **UDP + DTLS** | Optional für Broadcasts und Statusmeldungen mit leichter Sicherheitsschicht. | Lokale Discovery |
| **Peer Encryption** | Ende-zu-Ende-Verschlüsselung auf Anwendungsebene über AGLX-Header-Feld. | Direktkommunikation zwischen Agenten |

**Beispiel einer verschlüsselten Direktnachricht:**

<code diff>
AGLX/1.0 TCP
FROM: agent://alpha.local
TO: agent://beta.local
TYPE: task.assign
ENCRYPTION: aes256-gcm
CONTENT-TYPE: application/json

{
    "iv": "8h2G6fzx4VwP+YtN",
    "payload": "ENCRYPTED:df9d23bb...7f1a"
}
</code>

===== Integrität und Manipulationsschutz =====

Um sicherzustellen, dass Nachrichten unverändert ankommen, wird jede Nachricht mit einer Prüfsumme oder digitalen Signatur versehen.

^ Verfahren ^ Beschreibung ^
| **HMAC-SHA256** | Schnelles Verfahren für lokale Netze, Schlüsselbasiert |
| **RSA-SHA256** | Asymmetrische Signierung, geeignet für übergreifende Netzwerke |
| **ECDSA** | Kompaktes Signaturverfahren mit geringer Rechenlast |
| **Checksum-Header** | Fallback für unkritische UDP-Meldungen |

**Beispiel mit HMAC-Signatur:**

<code diff>
AGLX/1.0 TCP
FROM: agent://node51.local
TO: agent://node23.local
TYPE: task.result
HMAC: 3f1ad62f99bcb5e1bcd942ab38e0cf3c1dd06b9e
CONTENT-TYPE: application/json

{
    "task_id": "b912-a1d9-7ce3",
    "result": "OK",
    "credits_earned": 2
}
</code>

===== Zugriffskontrolle (Access Control) =====

Zugriffskontrolle in AGLX erfolgt dynamisch und rollenbasiert.  
Ein Agent kann definieren, welche Nachrichtentypen oder Aufgaben er akzeptiert.

**Beispiel einer Policy-Datei:**

<code diff>
{
    "accept": ["task.assign", "registry.update"],
    "deny": ["credit.transfer", "debug.dump"],
    "trusted_agents": ["agent://mentor01.local", "agent://router.global"],
    "max_concurrent_tasks": 5
}
</code>

^ Regeltyp ^ Beschreibung ^
| **Accept/Deny-Listen** | Filterung erlaubter Nachrichtentypen |
| **Trusted Agents** | Whitelist bekannter und vertrauenswürdiger Agenten |
| **Rate Limiting** | Begrenzung eingehender Aufgaben pro Zeitraum |
| **Credit Validation** | Prüfung, ob Absender über ausreichende Credits verfügt |

===== Datenschutz und Minimierung =====

Agenten sollten nur die notwendigsten Informationen teilen.  
Das gilt besonders für Registrierungs- und Monitoringdaten.

^ Maßnahme ^ Beschreibung ^
| **Anonymisierte Statusmeldungen** | Senden nur technischer Daten (z. B. uptime, load, status) |
| **Verzicht auf personenbezogene Daten** | Keine Userdaten oder Inhalte in Protokollnachrichten |
| **Temporäre Einträge** | Automatische Löschung in der Registry nach Ablauf der TTL |
| **Datenverschlüsselung im Cache** | Speicherung sensibler Inhalte nur verschlüsselt |

===== Sicherheitsrichtlinien für Entwickler =====

  - Alle TCP-Kommunikationen sollen TLS oder gleichwertige Verfahren nutzen.
  - UDP darf **nur für Discovery im LAN** eingesetzt werden (siehe IANA-Anpassung).
  - Jede Nachricht mit ökonomischem Wert (Credits, Reputation, Aufgaben) muss signiert werden.
  - Agenten sollten regelmäßig ihre Schlüssel erneuern (Key Rotation).
  - Mentoren und Registrys benötigen höhere Vertrauensstufen und erweiterte Signaturprüfung.

<box gh>
AGLX verfolgt das Prinzip der **„verteilten Sicherheit“**:  
Jeder Agent ist selbst dafür verantwortlich, Vertrauen aufzubauen, Nachrichten zu prüfen und seine Kommunikationspartner zu verifizieren.  
Sicherheit entsteht nicht durch zentrale Kontrolle, sondern durch konsequente Integrität auf allen Ebenen.
</box>

===== Versionierung =====
  * **Modul:** Sicherheit & Verschlüsselung  
  * **Version:** 1.0 (Draft)  
  * **Stand:** 27.10.2025
  * **Autor:** Andreas Röne (Konzept)