SSH Key PassCypher HSM PGP — Sécuriser l’accès multi-OS à un VPS

Résumé avancé — Architecture et flux SSH sécurisé via PassCypher HSM PGP

Pourquoi sécuriser SSH avec un HSM

Les clés SSH non chiffrées sont exposées au vol, aux copies et aux sauvegardes non souhaitées. PassCypher change le paradigme : la clé privée est encapsulée dans un conteneur chiffré et ne peut être utilisée qu’après déchiffrement contrôlé. L’injection matérielle de la passphrase (NFC / BLE-HID) supprime le besoin de taper la passphrase sur un clavier exposé aux keyloggers.

Architecture HSM PGP — éléments techniques

• Conteneur OpenPGP : AES-256 (CBC ou GCM selon implémentation) + MDC pour intégrité ;
• KDF durci : PBKDF2 (200k+) ou Argon2id (préféré si disponible) ;
• Passphrase : génération aléatoire dans le HSM (recommandation ≥ 256 bits pour posture « PQ-aware ») ;
• Injection : NFC pour déclenchement + émulateur BLE-HID pour saisie automatique et anti-keylogger ;
• Duplication sûre : fichiers *.key.gpg copiables (EviKey, NAS, QR imprimé) — sécurisés tant que la passphrase/KDF restent protégés.

Génération d’une clé SSH souveraine avec PassCypher HSM PGP

La génération d’une clé SSH est effectuée par le module EviSSH intégré à PassCypher HSM PGP, via le moteur EviEngine. Cette opération repose sur Git pour la création native de la paire de clés SSH, immédiatement encapsulée et chiffrée par PassCypher HSM PGP. Aucune donnée n’est transmise à un service tiers : tout le processus est exécuté localement.

Sélection d’algorithme — Choix cryptographique dans l’extension PassCypher

L’utilisateur sélectionne l’algorithme et la taille de clé directement depuis l’interface de l’extension web PassCypher HSM PGP. Les options disponibles sont regroupées par famille :

• RSA : 2048 bits · 3072 bits · 4096 bits
• ECDSA : 256 bits (p-256) · 384 bits (p-384) · 521 bits (p-521)
• EdDSA : ed25519 — recommandé pour sa robustesse, sa compacité et sa compatibilité native avec OpenSSH

Étapes de génération — Processus transparent via l’extension web

1. Ouvrir le module SSH dans PassCypher HSM PGP.
2. Choisir un nom de clé (label) unique, par ex. pc-hsm-pgp-ssh-key.
3. Sélectionner l’algorithme souhaité (ed25519 ou rsa-4096 selon le cas).
4. Définir la passphrase : saisie manuellement par l’utilisateur ou injectée via PassCypher NFC HSM avec son émulateur BLE-HID sécurisé AES-128 CBC). Cette passphrase est celle utilisée pour chiffrer la clé privée encapsulée par PassCypher HSM PGP.
5. Valider : EviSSH génère la paire SSH via Git, puis PassCypher HSM PGP chiffre la clé privée. Les fichiers sont automatiquement enregistrés dans le dossier défini par l’utilisateur (par défaut : ~/.ssh/ ou sur un support matériel tel qu’un EviKey NFC HSM).

Résultat — Artefacts exportés

• id_ed25519.pub — la clé publique, à copier sur le serveur distant.
• id_ed25519.key.gpg — la clé privée SSH chiffrée par PassCypher HSM PGP (conteneur OpenPGP AES-256 + KDF Argon2id/PBKDF2).

La passphrase, de préférence ≥256 bits d’entropie, peut être saisie depuis la mémoire humaine ou injectée automatiquement depuis le HSM via BLE-HID — évitant toute saisie sur un clavier exposé aux keyloggers.

Exemple réel — Clé privée RSA 4096 bits protégée par passphrase

Même une clé RSA 4096 bits, si stockée en clair, reste vulnérable. Dans PassCypher HSM PGP, elle est encapsulée et protégée par une passphrase de 141 bits d’entropie par défaut, rendant toute exfiltration ou brute-force mathématiquement irréaliste.

Voici à quoi ressemble une clé privée SSH RSA 4096 bits encapsulée au format OpenSSH, chiffrée par passphrase :

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABA+ghFLmp
Oiw0Z3A4NKn2gHAAAAGAAAAAEAAAIXAAAAB3NzaC1yc2EAAAADAQABAAACAQDK4d0ntIeb
... (contenu tronqué pour lisibilité) ...
55XA==
-----END OPENSSH PRIVATE KEY-----

Intégration sur VPS (ex. OVH Debian 12)

L’intégration d’une clé SSH PassCypher HSM PGP à un VPS s’effectue en insérant
la clé publique (.pub) dans le fichier authorized_keys du serveur.
OVH permet de le faire directement lors de la création du VPS via son tableau de bord.

Insertion manuelle post-déploiement

ssh -p 49152 debian@IPVPS "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys" < id_ed25519.pub

Ensuite, déchiffrez localement la clé privée depuis son conteneur chiffré :

gpg --decrypt --output ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.key.gpg
chmod 600 ~/.ssh/id_ed25519
ssh -i ~/.ssh/id_ed25519 -p 49152 debian@IPVPS

Le fichier déchiffré n’existe que temporairement : il peut être auto-effacé à la fin de la session SSH,
ou conservé dans la RAM si l’environnement est chiffré (tmpfs). Cette approche « zero-clear-text » garantit
qu’aucune donnée sensible ne subsiste sur disque.

Compatibilité multi-OS — Authentification universelle

Le format OpenSSH utilisé par PassCypher HSM PGP assure une compatibilité complète
avec les principaux systèmes d’exploitation. L’approche souveraine repose sur des standards ouverts
sans dépendance cloud ni service tiers.

Durcissement et bonnes pratiques SSH

Même avec une clé SSH PassCypher HSM PGP, la sécurité globale dépend du durcissement serveur.
Voici les recommandations clés pour une posture souveraine :

• Désactiver l’accès root : PermitRootLogin no
• Interdire les connexions par mot de passe : PasswordAuthentication no
• Limiter les utilisateurs SSH : AllowUsers admin
• Changer le port SSH : (ex. 49152) et bloquer le 22 par firewall
• Configurer UFW/iptables : politique DROP par défaut + exceptions ciblées
• Installer Fail2ban : (maxretry=3, bantime=30m) pour bloquer le brute-force
• Activer les journaux d’audit : journalctl -u ssh, rotation et ledger des connexions

FIDO vs SSH — Deux paradigmes, deux postures

Dans le paysage actuel de la cybersécurité, la confusion entre FIDO2/WebAuthn et SSH persiste, alors que ces technologies reposent sur des modèles d’authentification et de confiance fondamentalement différents.
FIDO sécurise une identité humaine dans le navigateur. SSH, lui, sécurise une identité machine dans le réseau.
Leur finalité, leur surface d’exposition et leur posture souveraine s’opposent dans la conception même.

FIDO2 / WebAuthn — Authentification centrée sur l’humain

• ↳ Conçu pour authentifier un utilisateur auprès d’un service Web (navigateur ↔ serveur via WebAuthn) ;
• ↳ La clé privée reste enfermée dans un authenticator matériel (YubiKey, TPM, Secure Enclave, etc.) ;
• ↳ Chaque site ou domaine crée une paire de clés unique — isolation des identités ;
• ↳ Dépendance à un serveur d’authentification (RP) et à l’écosystème navigateur ;
• ↳ Présence humaine obligatoire (biométrie, geste, contact) ;
• ↳ Clé non exportable : excellente sécurité, mais portabilité quasi nulle ;
• ↳ Pas de journal d’audit local ni de rotation autonome.

SSH — Authentification centrée sur la machine

• ↳ Conçu pour authentifier un système client auprès d’un hôte distant (VPS, serveur, cluster) ;
• ↳ Utilise une clé persistante, réutilisable sur plusieurs hôtes selon la politique de confiance ;
• ↳ Fonctionne sans navigateur : protocole SSH natif, échanges chiffrés machine ↔ machine ;
• ↳ Permet la duplication et la sauvegarde des clés (si chiffrées correctement) ;
• ↳ L’authentification repose sur une passphrase ou sur un HSM matériel (injection ou saisie locale) ;
• ↳ Journalisation native possible (logs SSH), rotation et révocation maîtrisées ;
• ↳ Indépendant du cloud, sans serveur d’identité tiers.

Synthèse stratégique

• FIDO2 : modèle cloud-centré et non-exportable — pour les services Web, mais limité hors navigateur ;
• SSH PassCypher : modèle souverain et portable — idéal pour les accès serveurs, VPS, ou environnements critiques ;
• PassCypher combine la sécurité matérielle d’un authenticator et la souplesse du SSH natif ;
• Les passphrases (≥ 256 bits) injectées via BLE-HID assurent une résistance post-quantique symétrique ;
• Les journaux d’audit et la rotation de clés offrent une traçabilité locale — hors des clouds FIDO ;
• Une même finalité : la confiance numérique, mais deux chemins : dépendance vs souveraineté.

Modèle de menace ⇢ comprendre les risques liés à SSH

Les connexions SSH classiques reposent sur des fichiers locaux contenant des clés privées.
Sans protection matérielle, ces fichiers peuvent être copiés, exfiltrés ou utilisés à distance.
Le modèle souverain mis en œuvre par SSH Key PassCypher HSM PGP vise à neutraliser
ces risques par une approche dite zéro-clé-en-clair et une segmentation stricte des secrets.

Menaces identifiées

• ▪ Vol de clé privée → exfiltration du fichier ~/.ssh/id_* ou de ses copies cloud.
• ▪ Dump mémoire → récupération en RAM d’une clé temporairement déchiffrée.
• ▪ Keylogger → capture de la passphrase lors d’une saisie clavier classique.
• ▪ MITM BLE → interception du signal lors d’un appairage “Just Works”.
• ▪ Sauvegarde non chiffrée → duplication accidentelle du conteneur sans contrôle d’accès.
• ▪ Erreur humaine → réutilisation ou diffusion non intentionnelle d’une clé.

⮞ Observation : la plupart des attaques réussies exploitent un seul facteur :
la présence d’une clé privée en clair sur disque, en mémoire ou pendant la saisie.

Mécanismes de protection techniques — OpenPGP, KDF et BLE-HID

Le modèle SSH Key PassCypher HSM PGP repose sur une défense en profondeur articulée autour de trois piliers : chiffrement asymétrique robuste, dérivation de clé renforcée et injection physique sécurisée. Ces mécanismes agissent conjointement pour garantir qu’aucune clé privée ne puisse être exfiltrée, même sur un poste compromis.

Conteneur OpenPGP et intégrité

Le fichier .key.gpg encapsule la clé privée OpenSSH dans un conteneur OpenPGP chiffré :

• Chiffrement : AES-256 (CBC ou GCM selon implémentation) ;
• Intégrité : MDC (Modification Detection Code) actif ;
• Salt unique : généré par le moteur lors du chiffrement initial ;
• Compression : optionnelle, pour réduire les empreintes mémoire.

Dérivation de clé (KDF) et résistance symétrique

La clé de session OpenPGP découle d’une passphrase issue du HSM via :

• Argon2id : configuration par défaut (m=512 MB, t=3, p=4), résistant aux attaques GPU ;
• Fallback PBKDF2 : 250 000 itérations SHA-512 si Argon2id indisponible ;
• Posture PQ-aware : entropie ≥ 256 bits → résistance symétrique équivalente à 2¹²⁸ (Grover).

⚠ Cette protection ne rend pas le système « post-quantum proof » : seules les primitives asymétriques PQC (CRYSTALS-Dilithium, Kyber) le permettront à terme.

Canal d’injection BLE-HID — Sécurisation de la passphrase

La passphrase est transmise via un canal Bluetooth Low Energy HID, émulant un clavier sécurisé.

• Appairage sécurisé : mode Secure Connections avec code PIN ou authentification par code numérique obligatoire, et bonding activé pour verrouiller l’association.
• Chiffrement des communications BLE : AES-128 CBC, appliqué au niveau de l’application HID.
• Stockage de la première clé AES-128 CBC : conservée dans une enclave électronique sécurisée intégrée à l’émulateur de clavier Bluetooth USB.
• Stockage de la seconde clé AES-128 CBC : protégée dans le Keystore Android (Android ≥ 10), via l’application PassCypher NFC HSM embarquée dans l’application Android Freemindtronic.
• Risque résiduel : une vulnérabilité MITM subsiste si le mode d’appairage « Just-Works » est autorisé — ce mode est strictement interdit dans la posture souveraine.

⮞ Summary : La combinaison OpenPGP + Argon2id + BLE-HID AES-128 constitue un écosystème cohérent : les secrets ne quittent jamais le périmètre chiffré, et le vecteur d’injection reste matériellement contrôlé.

Rotation et révocation — cycle de vie des clés SSH souveraines

La rotation d’une clé SSH Key PassCypher HSM PGP ne repose pas sur une commande de rotation de PassCypher Engine. Elle s’effectue selon un processus opératoire en quatre temps : régénérer, déployer, valider, retirer. Le tout en maintenant l’approche zero-clear-key (clé privée toujours chiffrée au repos, déverrouillage éphémère en RAM).

1) Régénération (nouvelle paire)

Depuis l’interface EviSSH intégrée à PassCypher HSM PGP, l’utilisateur régénère une paire de clés SSH via Git, encapsulée et chiffrée automatiquement par le moteur PassCypher. Voici comment :

• Sélectionner l’algorithme souhaité (recommandé : ed25519 pour robustesse et compatibilité ; rsa-4096 en cas de contrainte spécifique).
• Définir un label distinctif pour la paire (ex. : pc-hsm-ssh-2025-10) afin de faciliter la traçabilité et la révocation future.
• La clé privée est encapsulée automatiquement dans un conteneur OpenPGP chiffré (*.key.gpg) via AES-256 CBC et KDF durci (Argon2id ou PBKDF2 selon configuration).
• La clé publique (*.pub) est générée séparément et annotée avec un commentaire unique (ex. : pc-hsm-ssh-2025-10) pour identification dans authorized_keys.

2) Déploiement contrôlé (ajout sans coupure)

Ajouter la nouvelle .pub dans ~/.ssh/authorized_keys sur chaque serveur, sans supprimer l’ancienne (phase de chevauchement).

# Exemple de déploiement “append-only” (port 49152, utilisateur debian)
scp -P 49152 ~/.ssh/id_ed25519_2025-10.pub debian@IPVPS:/tmp/newkey.pub
ssh -p 49152 debian@IPVPS 'umask 077; mkdir -p ~/.ssh; touch ~/.ssh/authorized_keys \
&& grep -qxF -f /tmp/newkey.pub ~/.ssh/authorized_keys || cat /tmp/newkey.pub >> ~/.ssh/authorized_keys \
&& rm -f /tmp/newkey.pub && chmod 600 ~/.ssh/authorized_keys'

3) Validation (canary)

Tester la connexion avec la nouvelle clé (passphrase injectée via BLE-HID) :

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_2025-10 -p 49152 debian@IPVPS

Conserver les deux clés en parallèle sur une période courte (T + 24–72 h) pour absorber les aléas opérationnels.

4) Retrait de l’ancienne clé (révocation effective)

Retirer l’ancienne ligne d’authorized_keys par commentaire/label :

# Exemple : suppression par label de fin de ligne
ssh -p 49152 debian@IPVPS "sed -i.bak '/ pc-hsm-ssh-2025-04$/d' ~/.ssh/authorized_keys"

Répéter sur l’ensemble des hôtes cibles (bastion / nœuds). Archiver les fichiers authorized_keys.bak pour traçabilité.

Journal d’audit (append-only, côté admin)

Tenir un registre horodaté des opérations (empreintes, labels, hôtes) — simple, lisible, diff-able.

mkdir -p ~/audit && touch ~/audit/ssh-keys-ledger.tsv
printf "%s\tNEW\t%s\t%s\n" "$(date -Iseconds)" \
"$(ssh-keygen -lf ~/.ssh/id_ed25519_2025-10.pub | awk '{print $2}')" "pc-hsm-ssh-2025-10" \
>> ~/audit/ssh-keys-ledger.tsv
printf "%s\tREVOKE\t%s\t%s\n" "$(date -Iseconds)" \
"$(ssh-keygen -lf ~/.ssh/id_ed25519_2025-04.pub | awk '{print $2}')" "pc-hsm-ssh-2025-04" \
>> ~/audit/ssh-keys-ledger.tsv

Script d’orchestration (multi-hôtes, sans outil tiers)

#!/usr/bin/env bash
set -euo pipefail
PORT=49152
USER=debian
NEWPUB="$HOME/.ssh/id_ed25519_2025-10.pub"
OLD_LABEL="pc-hsm-ssh-2025-04"

while read -r HOST; do
  echo "[*] $HOST :: install new key"
  scp -P "$PORT" "$NEWPUB" "$USER@$HOST:/tmp/newkey.pub"
  ssh -p "$PORT" "$USER@$HOST" '
    umask 077
    mkdir -p ~/.ssh
    touch ~/.ssh/authorized_keys
    grep -qxF -f /tmp/newkey.pub ~/.ssh/authorized_keys || cat /tmp/newkey.pub >> ~/.ssh/authorized_keys
    rm -f /tmp/newkey.pub
    chmod 600 ~/.ssh/authorized_keys
  '
done < hosts.txt

echo "[] Validate the new key on all hosts, then retire the old key:"
while read -r HOST; do
  echo "[] $HOST :: remove old key by label"
  ssh -p "$PORT" "$USER@$HOST" "sed -i.bak '/ ${OLD_LABEL}$/d' ~/.ssh/authorized_keys"
done < hosts.txt

EviSSH — Gestion et orchestration intégrée

EviSSH n’est pas un outil externe ; il fait partie intégrante de PassCypher HSM PGP. Sa fonction est d’automatiser la génération, la gestion et la rotation des clés SSH locales, tout en assurant leur compatibilité universelle avec les environnements Linux, macOS et Windows. Il repose sur EviEngine pour orchestrer les actions du navigateur et du système, sans dépendance cloud ni service centralisé.

Fonctions principales

• Génération de clés SSH via Git, directement depuis l’interface PassCypher HSM PGP.
• Encapsulation automatique de la clé privée dans un conteneur chiffré OpenPGP (AES-256 + Argon2id/PBKDF2).
• Stockage souverain sur le support choisi : disque local, EviKey NFC HSM, NAS chiffré, etc.
• Rotation simplifiée : création, déploiement et révocation manuelle sans manipulation de fichier sensible.
• Interopérabilité totale : clés compatibles OpenSSH pour toutes plateformes majeures.

Sécurité et intégrations matérielles

• Injection de passphrase via PassCypher NFC HSM et canal BLE-HID chiffré (AES-128 CBC).
• Stockage matériel optionnel sur EviKey NFC HSM : les conteneurs chiffrés y sont inaccessibles sans la passphrase définie dans PassCypher.

Cas d’usage souverain — PassCypher HSM PGP · PassCypher NFC HSM & HID BLE

Points clés

Signaux faibles — tendances à surveiller

Ce que nous n’avons pas couvert