Key pillars

How it works

1. Define the storage split: Define where the external segment will reside (USB key, SD card, encrypted folder, or equivalent) while the local segment remains in browser local storage.
2. Create or import a secret: Create a new TOTP/HOTP secret or import an existing one (including QR-code enrollment workflows, when available in your environment).
3. Bind the origin: Define the reference login URL that the container will enforce during OTP injection.
4. Encrypt into a container: Generate the small PGP AES-256 CBC encrypted container that encapsulates the secret and its operational metadata.
5. Store segments separately: Save the external segment on the chosen medium. Confirm that the local segment remains only in local storage.
6. Use the OTP on demand: Navigate to the login page, then click the OTP action in the desktop workflow. The system validates domain integrity, decrypts in RAM, auto-fills and injects the OTP, and destroys decrypted material.
7. Share when required: If the operator needs delegated access, encrypt the container with a user-defined passphrase and transfer it via portable storage, QR workflows, or air-gapped channels. Access still requires segment conditions and URL validation.
8. Duplicate for resilience: Duplicate encrypted containers across controlled media as needed. Since the containers remain encrypted, duplication supports continuity without exposing cleartext.

For the host workflow context, refer to PassCypher HSM PGP: https://freemindtronic.com/how-passcypher-hsm-pgp-works/.

Unique added values

• Container-level sovereignty: Treat each OTP secret as a portable cryptographic object rather than an entry inside a centralized vault file.
• Operational duplication without decryption: Duplicate encrypted containers across controlled media to sustain access continuity without expanding cleartext exposure.
• Deterministic release conditions: Release an OTP only when segment presence and domain integrity conditions simultaneously hold.
• Reduced administrative coupling: Avoid mandatory services, accounts, or centralized telemetry paths that expand the attack surface through aggregation.
• Peer transfer without trust escalation: Share encrypted containers over constrained channels (including air gap) while preserving the same segmented enforcement logic at the point of use.
• Desktop-centric injection discipline: Keep the OTP workflow on the workstation that performs authentication, which reduces cross-device exposure paths introduced by mobile-to-desktop relay habits.

FAQ

Is EviOTP HSM PGP a standalone product?

No. The OTP manager capability powered by EviOTP HSM PGP is embedded in the PassCypher HSM PGP desktop application.

Which OTP standards does it support?

It supports TOTP and HOTP as defined by RFC 6238 and RFC 4226.

Where does the system store OTP secrets?

It stores each secret inside a small PGP AES-256 CBC encrypted container. The design splits decryption material across browser local storage and operator-controlled external media.

Does it require a master password?

No centralized master password is required by the architecture. However, when the operator shares containers, he or she can define a passphrase for transfer protection.

Can it work without internet access?

Yes. The workflow targets offline operation and does not require cloud services for OTP generation and use.

What prevents a stolen container from being used immediately?

The split-key condition blocks decryption if the attacker lacks one segment. Additionally, URL binding can block OTP injection on mismatched domains.

What does “decryption only in RAM” mean operationally?

The application decrypts the container only during the active OTP operation and then destroys decrypted material after injection, so routine use avoids writing cleartext secrets to disk.

Does it protect against phishing?

It can reduce OTP release on look-alike pages by validating domain integrity against the original login URL embedded in the container. Nonetheless, the operator must still verify context and intent.

How does sharing work without a server?

The operator can encrypt containers with a user-defined passphrase and move them via portable storage, QR-based transfer workflows, or air-gapped channels.

Can the operator duplicate containers for resilience?

Yes. Because containers remain encrypted, duplication supports continuity while preserving encrypted-at-rest conditions.

Does the design assume the host is untrusted?

Yes. The design avoids persistent decrypted storage on the host and relies on segmented storage to reduce the value of endpoint data theft.

Is Linux supported?

The provided specification states availability for Windows and macOS. If Linux support exists in a specific integration, document it explicitly in that release context.

Sovereign operational use case

An incident responder isolates a workstation after detecting an infostealer. The attacker exfiltrates files, browser data, and screenshots. However, the responder has enforced segment separation: one segment remains in browser local storage on the isolated workstation, while the external segment remains under physical custody on removable media. As a result, the stolen encrypted containers do not yield OTP secrets in isolation.

Next, the responder rebuilds a clean workstation, restores only encrypted containers, and reintroduces the external segment under controlled procedures. Then, he or she authenticates to recovery portals while the domain integrity check blocks OTP injection into look-alike pages generated during the breach. Consequently, the responder sustains access for containment and restoration, while limiting the operational blast radius of stolen data to encrypted artifacts that remain unusable without the missing segment and the correct domain context.