Generating a Sovereign SSH Key with PassCypher HSM PGP

SSH key creation occurs through the EviSSH module embedded in PassCypher HSM PGP using the EviEngine. It leverages Git to build the SSH key pair, then encrypts it instantly through PassCypher HSM PGP. The entire process stays local and offline.

Algorithm Selection — Cryptographic Choice within PassCypher

The user selects algorithm and key size directly in the PassCypher HSM PGP interface. Available families include:

• RSA: 2048 bits · 3072 bits · 4096 bits
• ECDSA: 256 bits (p-256) · 384 bits (p-384) · 521 bits (p-521)
• EdDSA: ed25519 — recommended for its robustness, compactness, and native OpenSSH support

Generation Steps — Transparent Workflow

1. Open the SSH module inside PassCypher HSM PGP.
2. Define a unique key label, for example pc-hsm-pgp-ssh-key.
3. Select the desired algorithm (ed25519 or rsa-4096).
4. Set a passphrase, either typed manually or injected via PassCypher NFC HSM using its BLE-HID AES-128 CBC emulator. This passphrase encrypts the private key container.
5. Validate the action. EviSSH generates the pair through Git, and PassCypher HSM PGP encrypts the private key. Files save automatically in the chosen path, by default ~/.ssh/ or an EviKey NFC HSM.

Result — Exported Artifacts

• id_ed25519.pub — public key copied to the remote server.
• id_ed25519 — private key encrypted by PassCypher HSM PGP in native OpenSSH format (AES-256 + bcrypt KDF)

The passphrase, ideally ≥ 256 bits of entropy, can be typed or injected from the HSM via BLE-HID, avoiding exposure to keyloggers.

Memorable Passphrase Generator — “Two Words + Symbol” Option

The built-in generator:

• Selects random words from an embedded wordlist.
• Inserts 1–3 special characters between or around words.
• Displays an estimated entropy score.
• Optionally stores the passphrase in the HSM or injects it via BLE-HID during container encryption.

Practical Example

Generate a 3-word passphrase with two special characters:

# Example (PassCypher interface)
1) Choose wordlist: common-wordlist-16k
2) Words: 3
3) Separator: '-'; special chars: '#!'
→ Example output: atlas-siren#!

Use PassCypher NFC HSM to inject it via BLE-HID during encryption:

ssh-keygen -p -o -a 16 -t ed25519 -f ~/.ssh/id_ed25519 --output id_ed25519.key.gpg --compress-level 0 id_ed25519
# Passphrase is injected by PassCypher BLE-HID at pinentry prompt

Operational Recommendations

• For critical servers or bastions, prefer HSM generation or increase word count.
• Enable bcrypt with m ≥ 512 MB, t ≥ 3, p ≥ 4 during encryption.
• Never store the passphrase in plain text or unprotected form.
• Check entropy estimation in UI and adjust with extra words or symbols if required.

ASCII-95 Generator — High-Entropy Password / Passphrase Mode

The interface below creates ultra-secure passwords or passphrases using all 95 printable ASCII characters. Unlike word-based modes, this option targets maximum entropy and granular control over character classes. It provides real-time entropy estimation, often ≥ 256 bits depending on length. It is meant for use cases where the secret remains encrypted (QR or HSM) and is injected via PassCypher ecosystem (BLE-HID / NFC) without screen display.

QR Code Export — Direct Transfer to PassCypher NFC HSM

Once a high-entropy password or passphrase is generated through the ASCII-95 module, the user can export the secret as an encrypted QR Code. This code can then be scanned by an Android smartphone with NFC running the Freemindtronic app that includes PassCypher NFC HSM. This sovereign interoperability enables direct transfer from the software HSM to the hardware HSM without network exposure or disk writes. Afterward, PassCypher NFC HSM can inject the secret through its Bluetooth HID keyboard emulator for authentication on any SSH client.

Real-World Example — RSA 4096-bit Private Key Protected by Passphrase

Even an RSA 4096-bit key becomes vulnerable if stored unencrypted. Within PassCypher HSM PGP, the key remains encapsulated and protected by a 141-bit entropy passphrase by default, making brute-force or exfiltration mathematically infeasible. Below is what an OpenSSH-formatted RSA 4096-bit private key looks like once encrypted by passphrase:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABA+ghFLmp
Oiw0Z3A4NKn2gHAAAAGAAAAAEAAAIXAAAAB3NzaC1yc2EAAAADAQABAAACAQDK4d0ntIeb
... (truncated for readability) ...
55XA==
-----END OPENSSH PRIVATE KEY-----

After securing key generation and encapsulation, administrators can integrate the sovereign SSH key into their virtual servers. The next section explains how to deploy it on Debian-based VPS instances like OVHcloud.

Integration on VPS (Example – OVH Debian 12)

Integrating a PassCypher HSM PGP SSH key into a VPS involves placing the public key (.pub) inside the server’s authorized_keys file.
OVHcloud allows inserting it directly during VPS creation through its dashboard.

Manual Insertion After Deployment

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

Then decrypt the private key locally from its encrypted container:

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

The decrypted file exists only temporarily. It can self-erase after the SSH session or stay in RAM if mounted on tmpfs.
This “zero-clear-text” approach ensures that no sensitive data persist on disk.

Once integrated on a server, the same sovereign SSH key can authenticate securely across multiple operating systems.
The following section details how PassCypher HSM PGP maintains this universal compatibility.

Cross-OS compatibility — Universal authentication

The OpenSSH format used by PassCypher HSM PGP guarantees full compatibility with major operating systems. The sovereign design is based on open standards only — no cloud dependencies, no third-party identity services.

Official reference — Microsoft: Key-based SSH authentication on Windows (March 10, 2025)

On March 10, 2025 Microsoft updated guidance for OpenSSH key-based authentication on Windows. The document covers creating and managing public/private key pairs and recommends modern asymmetric algorithms (Ed25519, ECDSA, RSA, DSA).

• Published: March 10, 2025 — Microsoft Learn
• Scope: OpenSSH key management and secure key storage on Windows
• Tools & commands: ssh-keygen, ssh-agent, ssh-add, sshd, PowerShell automation, scp, sftp
• Key files: authorized_keys, administrators_authorized_keys, id_ecdsa.pub, default folder C:\Users\username\.ssh\
• Algorithms supported: Ed25519, ECDSA, RSA, DSA
• Best practices: strong passphrase encryption, MFA where applicable, strict file permissions
• Limitation: passphrases are typically typed or managed by software agents — an exposure vector in conventional setups

Sovereign extension of the model

• Passphrases are injected from hardware (NFC / BLE-HID) — no manual typing, no clipboard exposure.
• Private keys are protected in an OpenSSH private key format (AES-256 + hardened KDF), preventing any cleartext private key from leaving ephemeral memory.

Combined with OpenSSH on Windows, PassCypher HSM PGP converts Microsoft’s key-based flow into a hardware-anchored sovereign SSH suitable for Zero-Trust and PQ-aware postures.

PowerShell SSH

PowerShell (Windows 11 / Windows Server 2025) includes native OpenSSH integration and automation capabilities. When combined with PassCypher HSM PGP, remote operations can be automated while keeping the passphrase bound to hardware (HSM), avoiding exposure in process memory — an auditable, sovereign automation model.

Sovereign SSH

The hybrid hardware approach embodied by PassCypher HSM PGP implements Sovereign SSH: local key generation inside HSM, OpenSSH passphrase encryption (AES-256), hardened KDFs, typological key rotation — all without cloud or federated identity dependencies. This layer strengthens Microsoft OpenSSH’s trust chain with an auditable, PQ-aware hardware boundary.

Git for Windows integration — SSH key generation

PassCypher HSM PGP uses the Git for Windows environment to generate and manage SSH key pairs. Git for Windows ships ssh-keygen.exe, enabling creation of keys protected by a passphrase. By default keys are placed in the user folder:

C:\Users\\.ssh\

This default placement ensures full compatibility with PowerShell SSH and OpenSSH on Windows while allowing PassCypher to add an additional sovereign protection layer (OpenSSH passphrase encryption + HSM-based passphrase injection), producing a double barrier consistent with the zero-clear-key principle.

Functional SSH Key Separation — Authentication vs Signature

In a sovereign SSH architecture, each key must serve a clearly defined function to minimize exposure risks and enhance traceability. PassCypher HSM PGP enforces this typological separation by encrypting each private key individually within an OpenSSH private key format (AES-256 + hardened KDF), each labeled and fingerprinted according to its role:

• Authentication key: used exclusively to establish secure SSH connections to remote servers. The private key’s passphrase is injected via BLE-HID from a PassCypher NFC HSM, entered manually, or pasted locally. PassCypher never displays or transmits this passphrase in cleartext—neither on disk nor in persistent memory—ensuring strict compliance with the Zero-Clear-Key principle. The user remains responsible for clipboard and terminal security when typing or pasting manually.
• Signature key: used for cryptographic validation of files, scripts, or Git commits. It is encapsulated in a separate OpenSSH private key format, traceable and revocable without affecting SSH access.

This encrypted separation enables:

• Targeted revocation without disrupting active SSH sessions (revocation date management is planned in future PassCypher SSH releases)
• Enhanced auditability through functional labeling and local logging
• Native DevSecOps compatibility (Git, CI/CD, signed pipelines)

Server Hardening and Best Practices for SSH Key PassCypher HSM PGP

Even with a PassCypher HSM PGP SSH key, overall security depends on server configuration. Key recommendations for a sovereign posture include:

• • • Disable root login: PermitRootLogin no
    • Forbid password authentication: PasswordAuthentication no
    • Restrict SSH users: AllowUsers admin
    • Change default port: use 49152 and block 22 via firewall.
    • Configure UFW or iptables: default DROP policy with targeted exceptions.
    • Enable Fail2ban: maxretry = 3, bantime = 30 min to block brute-force attacks.
    • Activate audit logs: journalctl -u ssh with rotation and ledger tracking.

FIDO vs SSH — Two Paradigms, Two Security Postures

In the evolving cybersecurity landscape, confusion between FIDO2/WebAuthn and SSH remains common. These two systems rely on fundamentally different trust models and authentication paradigms. FIDO secures a human identity in the browser, while SSH secures a machine identity within the network. Their purposes, exposure surfaces, and sovereignty principles diverge completely.

FIDO2 / WebAuthn — Human-Centric Authentication

• • • ↳ Designed to authenticate a user to a web service (browser ↔ server via WebAuthn).
    • ↳ The private key stays sealed within a hardware authenticator (YubiKey, TPM, Secure Enclave, etc.).
    • ↳ Each site or domain creates a unique key pair — ensuring identity isolation.
    • ↳ Relies on an authentication server (RP) and the browser ecosystem.
    • ↳ Requires human presence (biometric, touch, or gesture).
    • ↳ Non-exportable key: strong security but minimal portability.
    • ↳ No local audit trail or autonomous key rotation.

SSH — Machine-Centric Authentication

• • • ↳ Designed to authenticate a client system to a remote host (VPS, server, or cluster).
    • ↳ Uses a persistent key, reusable across hosts according to trust policy.
    • ↳ Operates outside browsers — native SSH protocol with encrypted machine-to-machine exchanges.
    • ↳ Allows duplication and backup of keys when securely encrypted.
    • ↳ Relies on a passphrase or hardware HSM for local or injected authentication.
    • ↳ Supports native logging, rotation, and revocation controls.
    • ↳ Fully independent of cloud or third-party identity providers.

⮞ What PassCypher HSM PGP with EviSSH Brings

The SSH Key PassCypher HSM PGP solution extends classic SSH by introducing hardware security and auditability similar to FIDO2 — but within a cloudless sovereign architecture. It brings trust, portability, and compliance into a unified zero-trust framework:

• • • → Local SSH key pair generation through PassCypher Engine / EviSSH.
    • → Private key encrypted in its OpenSSH private key format (AES-256 + bcrypt KDF).
    • → Key always encrypted on disk — decryption happens only in volatile memory.
    • → Hardware passphrase injection via PassCypher NFC HSM or BLE-HID emulator using AES-128 CBC encryption.
    • → Optional physical presence adds a “sovereign gesture” equivalent to FIDO authentication.
    • → Full cross-platform support: Linux, macOS, Windows, Android, and iOS.
    • → No dependency on browsers, WebAuthn servers, or cloud identity accounts.
    • → Orchestrated key rotation and archival via EviSSH for industrial or defense-grade use.

Strategic Summary

• • • FIDO2: Cloud-centric, non-exportable — ideal for web identity, but limited outside browsers.
    • SSH PassCypher: Sovereign, portable — ideal for servers, VPS, and critical infrastructure access.
    • PassCypher merges the hardware assurance of authenticators with the flexibility of native SSH.
    • BLE-HID injected passphrases (≥ 256 bits) ensure post-quantum symmetric resistance.
    • Local audit trails and key rotation enable off-cloud traceability.
    • Both pursue digital trust, but through opposite paths — dependence vs. sovereignty.

Threat Model — Understanding SSH Risks

Before addressing mitigation, it is essential to understand how traditional SSH keys introduce vulnerabilities. Standard SSH connections rely on local files containing private keys. Without hardware protection, these files can be copied, exfiltrated, or reused remotely. The sovereign model deployed in SSH Key PassCypher HSM PGP neutralizes these vectors through zero-clear-key architecture and strict secret segmentation.

Identified Threats

• • • Private key theft — exfiltration of ~/.ssh/id_* or cloud-synced copies.
    • Memory dump — retrieval of a key temporarily decrypted in RAM.
    • Keylogger — passphrase capture during manual keyboard entry.
    • BLE MITM — interception during insecure “Just Works” pairing.
    • Unencrypted backup — uncontrolled duplication of the container file.
    • Human error — key reuse or unintended disclosure.

SSH Private Key Breaches (2021–2025) — Why OpenSSH AES-256 + HSM-injected passphrase would have prevented them

AI-Assisted Breach Vectors — and Why Hardware Sovereignty Matters

Short summary: Since 2021, multiple public incidents have exposed a recurring vulnerability: plaintext secrets or private keys accessible in CI pipelines, memory, or logs. Today, AI-assisted IDEs and Copilot-like assistants extend that exposure surface by indexing local workspace data, terminal outputs, and editor buffers. When an AI assistant can read or summarize visible code or system logs, any plaintext secret becomes an implicit exfiltration vector.

Documented, verifiable examples

• • • Codecov supply-chain compromise (2021) — CI scripts leaked plaintext credentials. Hardware encryption (OpenSSH AES-256 + HSM passphrase injection) would have rendered them useless.
    • Ebury SSH backdoors (2009 – 2024) — malware stole SSH keys in memory. Zero-clear-key workflows prevent such exfiltration.
    • Public key leaks (GitHub, 2023 – 2024) — accidental commits of secrets. OpenSSH-encrypted private key files remain inert if exposed.

AI / IDE assistants — new attack surface

Modern code assistants (GitHub Copilot, Amazon CodeWhisperer, etc.) scan active projects and terminals to provide context-aware suggestions. If plaintext secrets exist in that context, they may be processed or exposed inadvertently. Independent audits and vendor advisories highlight potential privacy and data-leak risks when assistants index developer environments without isolation.

Why hardware sovereignty eliminates this risk

• • • Private keys remain sealed in OpenSSH AES-256 containers.
    • Decryption requires a hardware-held passphrase injected via BLE-HID or NFC.
    • No plaintext key or passphrase ever appears on screen, disk, or in clipboard memory.

Even if an AI assistant, IDE plugin, or CI process is compromised, it cannot extract usable secrets — because none exist in cleartext. PassCypher HSM PGP enforces this “zero-clear-key” model from key generation to authentication.

Protection Mechanisms — OpenSSH, KDF, and BLE-HID Layers

After defining the threat surface, PassCypher HSM PGP establishes a defense-in-depth model built on three pillars: robust asymmetric encryption, hardened key derivation, and secure physical passphrase injection. Together, these mechanisms ensure that no private key can be extracted — even from a compromised endpoint.

OpenSSH private key format and Integrity Assurance

The private key is stored directly in OpenSSH’s native encrypted format (AES-256 + bcrypt).

• • • Encryption: AES-256 (CTR, CBC, or GCM depending on configuration)
    • Integrity: Active MDC (Modification Detection Code).
    • Unique salt: generated by the engine during initial encryption.
    • Optional compression: reduces memory footprint and transmission load.

Key Derivation Function (KDF) and Symmetric Resistance

The OpenSSH encryption key derives from an HSM-generated passphrase:

• • • bcrypt: default mode (m=512MB, t=3, p=4) hardened against GPU attacks.
    • PBKDF2 fallback: 250,000 SHA-512 iterations when bcrypt is unavailable.
    • Post-quantum awareness: ≥256-bit entropy ensures symmetric strength equivalent to 2¹²⁸ under Grover’s bound.

BLE-HID Injection Channel — Passphrase Security at the Hardware Layer

The passphrase travels through a Bluetooth Low Energy HID channel emulating a hardware keyboard.

• • • Secure pairing mode: Secure Connections enforced with numeric authentication (PIN or code), bonding activated for persistence.
    • Communication encryption: AES-128 CBC applied at HID application level.
    • First AES-128 key stored in a secure enclave embedded in the Bluetooth keyboard emulator.
    • Second AES-128 key stored inside Android Keystore (Android ≥ 10) managed by the PassCypher NFC HSM app.
    • Residual risk: a MITM vulnerability can appear if “Just Works” mode is allowed — this mode is strictly forbidden under sovereign policy.

Rotation and Revocation — SSH Key PassCypher HSM PGP Lifecycle Management

Within sovereign SSH authentication infrastructures, key rotation ensures continuity and traceability without exposing secrets. Unlike simple rotation commands, SSH Key PassCypher HSM PGP follows a four-step operational process: regenerate, deploy, validate, revoke. This method fully preserves the zero-clear-key principle — private keys stay encrypted at rest and are decrypted only in volatile memory.

1) Regeneration — Creating a New Sovereign SSH Key Pair

From the integrated EviSSH interface, users regenerate SSH key pairs through Git. The PassCypher Engine automatically encapsulates and encrypts them.

• • • Select the algorithm — ed25519 for resilience and interoperability, or rsa-4096 for specific requirements.
    • Assign a distinct label (e.g., pc-hsm-ssh-2025-10) to ensure traceability and simplify future revocation.
    • The private key is encapsulated in an OpenSSH AES-256 encrypted container (id_ed25519 or id_rsa) using a hardened KDF (bcrypt).
    • The public key (*.pub) is generated with a unique comment identifier for use in authorized_keys.

2) Controlled Deployment — Adding Without Downtime

Append the new .pub key to ~/.ssh/authorized_keys on each server without removing the previous one.

# Append-only deployment (port 49152, Debian user)
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 Phase

Test connectivity with the new key. The passphrase is injected securely via BLE-HID from the HSM.

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

Maintain both keys for 24–72 hours to ensure seamless operational continuity.

4) Revocation — Retiring the Old Key

Remove the previous key entry using its label comment.

# Remove key by label match
ssh -p 49152 debian@IPVPS "sed -i.bak '/ pc-hsm-ssh-2025-04$/d' ~/.ssh/authorized_keys"

Repeat across all target hosts. Archive authorized_keys.bak for forensic traceability.

Audit Ledger — Append-Only Record

Maintain a timestamped ledger of key lifecycle operations.

mkdir -p ~/audit && touch ~/audit/ssh-keys-ledger.tsv
printf "%stNEWt%st%sn" "$(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 "%stREVOKEt%st%sn" "$(date -Iseconds)" 
"$(ssh-keygen -lf ~/.ssh/id_ed25519_2025-04.pub | awk '{print $2}')" "pc-hsm-ssh-2025-04" 
>> ~/audit/ssh-keys-ledger.tsv

Multi-Host Orchestration Script — Without Third-Party Tools

#!/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

Sovereign Methods for Passphrase or Password Recovery

PassCypher HSM PGP provides several sovereign recovery mechanisms for SSH authentication secrets. Each method follows the zero-clear-key rule and adapts to operational contexts:

• • • Encrypted QR Code (GIF/PNG) — Import a passphrase without display. Ideal for printed backups or planned rotations. → Injects directly into secure input fields.
    • NFC Retrieval from PassCypher HSM — Contactless recovery from sovereign hardware (EviKey or EviPass). → Automatic encrypted injection through BLE-HID channel.
    • Bluetooth or USB Keyboard Emulator (BLE-HID) — AES-128 CBC encrypted keystroke emulation. Works on Linux, macOS, Windows, Android, and iOS, even air-gapped. → Leaves no persistent trace.
    • Manual Memory Entry — Expert-only option: direct entry in secure pinentry. → Sovereign if no autocomplete or logging is active.

Advanced CLI FIFO Example — For Expert Linux Operators

# 1. Create a secure FIFO
mkfifo /tmp/pc_pass.fifo
chmod 600 /tmp/pc_pass.fifo

# 2. Decrypt via FIFO without storing passphrase
gpg --batch --yes --passphrase-fd 0 --decrypt --output ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.key.gpg < /tmp/pc_pass.fifo & # 3. Write the passphrase transiently, then destroy FIFO printf '%s' "THE_PASSPHRASE" > /tmp/pc_pass.fifo
shred -u /tmp/pc_pass.fifo || rm -f /tmp/pc_pass.fifo

Operational Flow — From Generation to Authentication (SSH Key PassCypher HSM PGP)

The operational flow defines how PassCypher Engine, PassCypher HSM PGP, and optionally the PassCypher NFC HSM with its BLE-HID keyboard emulator collaborate to generate, protect, transport, and authenticate an SSH key whose private component remains encrypted and is only unlocked ephemerally in RAM.
This architecture forms the backbone of the sovereign SSH authentication lifecycle.

Detailed Steps (Flow)

Generation (EviSSH Integrated in PassCypher HSM PGP, Orchestrated by PassCypher Engine)

▸ The user launches PassCypher Engine or the extension → “SSH Key Generator.”
▸ Selects algorithm (ed25519 recommended).
▸ Defines a label and passphrase method (generated by the HSM or user-specified).
▸ Result: key pair → id_ed25519 (OpenSSH private key encrypted with passphrase) + id_ed25519.pub (public key).
▸ EviSSH suggests secure storage (local folder, EviKey, encrypted NAS). No automatic unlock is performed.

Export & Secure Storage

▸ Export only the public key (.pub) to the server (e.g., OVH, Scaleway, etc.).
▸ Store the encrypted private key (OpenSSH PEM block protected by passphrase) securely: on EviKey NFC, encrypted NAS, or USB drive. The file remains encrypted at rest.

Client Preparation Before Use

▸ Copy the encrypted private key to a controlled directory on the client (e.g., ~/secure/id_ed25519).
▸ Optionally, mount a tmpfs to avoid disk persistence during temporary decryption:

sudo mkdir -p /mnt/ssh-tmp && sudo mount -t tmpfs -o mode=700 tmpfs /mnt/ssh-tmp

▸ Disable or encrypt swap: sudo swapoff -a.

Passphrase Injection (PassCypher NFC HSM → BLE-HID)

▸ The user triggers passphrase injection by bringing the PassCypher NFC HSM near the smartphone or pairing the BLE-HID if not yet bonded.
▸ Security Note — never allow “Just-Works” pairing. Require Secure Connections (Numeric Comparison or PIN) and enforce bonding.
▸ The BLE channel transmits encrypted packets (AES-128 CBC). The device injects the passphrase as a virtual keyboard input — no manual typing.

Ephemeral Decryption in RAM

▸ The OpenSSH prompt requests the passphrase; PassCypher BLE-HID injects it securely.
▸ The private key decrypts only in volatile memory for immediate use.
▸ The id_ed25519 or id_rsa container remains encrypted and intact.
▸ For temporary files, enforce chmod 600 and avoid disk writes when possible.

SSH Authentication

▸ SSH uses the decrypted key in memory:

ssh -i /path/to/id_ed25519 -p 49152 user@IPVPS

▸ Once authenticated, purge the key immediately from memory.

Purge & Post-Usage

▸ If a temporary file was used, delete and unmount it:

shred -u /mnt/ssh-tmp/id_ed25519 || rm -f /mnt/ssh-tmp/id_ed25519
sudo umount /mnt/ssh-tmp

▸ Remove SSH agent sessions: ssh-add -D and eval "$(ssh-agent -k)".
▸ Reactivate swap if needed: sudo swapon -a.

Quick Command Examples

# Example: temporary RAM decryption
sudo mkdir -p /mnt/ssh-tmp && sudo mount -t tmpfs -o mode=700 tmpfs /mnt/ssh-tmp
cp /media/evikey/id_ed25519 /mnt/ssh-tmp/id_ed25519
ssh -i /mnt/ssh-tmp/id_ed25519 -p 49152 user@vps.example.com
shred -u /mnt/ssh-tmp/id_ed25519 || rm -f /mnt/ssh-tmp/id_ed25519
sudo umount /mnt/ssh-tmp

EviSSH — Integrated Management & Orchestration

EviSSH is not an external utility but an integrated part of PassCypher HSM PGP. It automates SSH key generation, rotation, and management locally while maintaining universal compatibility across Linux, macOS, and Windows. It operates under EviEngine, orchestrating system-level actions with no cloud or third-party dependency — ensuring trusted and sovereign SSH key management.

Main Capabilities

• • • SSH Key Generation via Git, directly within the PassCypher HSM PGP interface.
    • Automatic Encryption of the private key into an OpenSSH private key format (AES-256 + bcrypt).
    • Sovereign Storage on local drives, EviKey NFC HSM, or encrypted NAS devices.
    • Simple Rotation: creation, deployment, and revocation without handling plaintext keys.
    • Full Interoperability: OpenSSH-compatible keys across all major platforms.

Security and Hardware Integration

• • • Passphrase Injection via PassCypher NFC HSM using an AES-128 CBC encrypted BLE-HID channel.
    • Optional Hardware Storage on EviKey NFC HSM — encrypted containers remain inaccessible without the defined passphrase.

Sovereign Use Case — PassCypher HSM PGP × PassCypher NFC HSM & BLE-HID

Key Insights

Weak Signals — Emerging Trends in Sovereign SSH Security

What We Haven’t Covered — Beyond SSH Key PassCypher HSM PGP