Signature des payloads d'agent

Depuis la ronde de durcissement de mai 2026, chaque agent signe ses payloads d’ingestion avec une clé de paire Ed25519 propre. Le seul token bearer du hub n’est pas suffisant pour envoyer des données au nom d’un agent — l’attaquant a également besoin de la clé de signature privée de l’hôte.

Comment ça marche

Agent (première exécution)
  ├─ génère une paire de clés Ed25519
  ├─ écrit le secret dans /var/lib/monsys/agent-signing.key  (mode 0600)
  └─ envoie la clé publique au hub via /api/v1/agents/register
                                          │
                                          ▼
                              Le hub stocke la clé dans agents.signing_pubkey
                              (trust-on-first-use)

Agent (chaque ingestion)
  corps = "[{...métriques...}]"
  sig  = base64(Ed25519(SHA256(body)))
  HTTP POST /api/v1/ingest
    Authorization: Bearer ms_...
    X-Monsys-Signature: <sig>

Hub
  pubkey = SELECT signing_pubkey FROM agents WHERE token_hash = …
  si pubkey NULL    → accepter + logger "payload non signée" (moyen)
  si sig manquant  → 403 + logger "payload non signée" (élevé)
  si sig incorrecte       → 403 + logger "signature invalid" (critique)
  sinon             → ✓ traiter

Emplacement du fichier

Plateforme	Chemin
Linux	/var/lib/monsys/agent-signing.key
Windows	C:\ProgramData\monsys\agent-signing.key

Permissions sur Linux : mode 0600, propriétaire = l’utilisateur qui exécute l’agent (user/monsys en fonction de votre installation). Windows : ACL limitée à SYSTEM + Administrateurs.

Contenu est 32 octets (seed secrète Ed25519 brute). Pas de header, pas de PEM — gardez le fichier exactement sur cette taille.

Sématique trust-on-first-use

La première fois qu’un agent envoie une clé publique dans register, le hub la stocke et met signing_set_at = NOW(). Par la suite, la pin est immuable de l’agent — une nouvelle clé publique sera refusée et générera une anomalie d’intégrité signature_invalid.

Pour faire pivoter légitimement, un administrateur doit explicitement désactiver la pin via :

POST /api/v1/agents/<id>/rotate-signing-key

(voir Rotation de jetons)

Ce que peut faire un attaquant avec uniquement le token bearer pas

Attaque	Bloqué par
Faux push de métriques sous la même agent	décalage de signature → 403
Trip honeypot valsemblable	décalage de signature → 403
Hash DNA du processus remplacé	décalage de signature → 403
Version downgrade dans les rapports	décalage de signature → 403, plus vérification d’intégrité version_downgrade

Ce que peut faire un attaquant avec token + fichier clé

Si les deux sont volés, l’attaquant peut rapporter intégralement au nom de l’agent. Le fichier clé se trouve cependant en dehors /etc/ (où les backups des configurations système typiquement s’y trouvent), et est mode 0600. Mesures concrètes pour empêcher que les deux ne soient pas volés ensemble :

• Évitez d’inclure le fichier clé dans les backups (backup_exclude dans restic / borg)
• Faites pivoter la clé de signature après un événement de sécurité constaté
• Suivez les modifications sur /var/lib/monsys/agent-signing.key avec l’outil FIM (auditd) de votre hôte (auditctl -w /var/lib/monsys/agent-signing.key -p wa)

Migration des installations existantes

Un agent plus ancien sans module de signature fonctionne toujours : le hub accepte la payload non signée mais crée une anomalie unsigned_payload chaque heure pour que cela ne passe pas inaperçu.

Voici l’ordre d’exécution :

# Sur l'hôte
sudo apt update && sudo apt upgrade monsys-agent
# Ou via le script d'installation :
curl -fsSL https://get.monsys.ai/install.sh | sudo bash
sudo systemctl restart monsys-agent

L’agent génère alors une paire de clés, enregistre la clé publique et les anomalies unsigned_payload se ferment automatiquement dans le cycle d’intégrité suivant (10 min).