This is my small contribution to the forum. A reference guide/bridge document born out of my exploratory research for use cases regarding the Vivokey Flex family of implants. I hope it’ll be of help to. If you spot anything that needs correcting, let me know but otherwise do with it as you will, feel free to build off of it.
Thanks to @Pilgrimsmaster for the initial review!
PS. The duress applet and behavioural analytics code wont be shared due to opsec.
VivoKey flexSecure — Practical Reference
April 2026 · Not affiliated with Dangerous Things or VivoKey
A working reference for the VivoKey flexSecure NFC implant as a hardware-bound cryptographic anchor. Covers hardware selection, placement, setup sequence, what the chip can do today, and operational failure modes.
> Scope
Covers: hardware specs, applet stack, GPG/SSH/FIDO2 setup, continuous authentication, duress framework, key lifecycle, audit, recovery, and failure modes.
Not covered here: threshold signing, DeFi/on-chain applications, post-quantum migration. A separate technical analysis covers the full design space.
Minimum viable configuration
FIDO2 registration and basic GPG key generation are a complete, usable configuration on their own. You do not need to implement continuous authentication, the duress framework, or threshold signing to get significant value from the hardware. Each section is independently usable. Start with what you need and add the rest only when you have a specific reason to.
1. Hardware
1.1 The chip
The VivoKey flexSecure uses an NXP JCOP4 / SmartMX3 P71 secure element, the same chip class as EU biometric passports, banking SIMs, and government identity cards. Common Criteria EAL6+ certified. All cryptographic operations execute on-chip. The private key is never exposed to the NFC interface and cannot be extracted through any command or interface the chip exposes.
| Specification | Value | Note |
|---|---|---|
| Chip | NXP JCOP4 / SmartMX3 P71 | Same class as EU biometric passports |
| Certification | Common Criteria EAL6+ | Resistance to extraction under evaluated conditions |
| EEPROM storage | 167,736 bytes | Full applet suite with significant headroom |
| Dimensions | 7.5 × 28 × 0.4mm | Narrow flex — incision install, not needle punch |
| NFC frequency | 13.56 MHz ISO 14443-A | Compatible with any standard PC/SC reader |
| NFC read range | 1–3cm | Deliberate positioning required |
| Power | Passive inductive | No battery. No signal unless actively queried. |
| MRI compatibility | Compatible | Confirm blanket policies with specific facility |
| Metal detectors | Does not trigger | No ferromagnetic components |
| Border crossings | No signal unless queried | Passive device — invisible without an active reader |
| Rated lifespan | 50+ years | EEPROM write cycles are the practical constraint |
1.2 Hardware Variants & Installation Methodology
The flexSecure platform is available in three form factors, each with distinct installation requirements and placement considerations. The “Narrow” flex is the most common, but the “Module” and “Spectrum” variants offer different trade-offs in terms of footprint and antenna geometry.
| Variant | Form Factor | Installation Method | Critical Notes |
|---|---|---|---|
| Narrow Flex | 7.5mm x 28mm (Rectangular) | Incision (Scalpel) or Custom Large-Bore Needle (12G+). | Standard 5mm biohacking needles are too small for the 28mm length of the Narrow flex. Attempting a needle punch with a standard needle will damage the PCB. Incision is the recommended method for reliability. |
| Module | Larger PCB (Square/Rect) | Incision required. | The larger footprint makes this variant unsuitable for the wrist or fingers. Best placed in the upper arm or chest where tissue stability is higher and movement stress is lower. |
| Spectrum | Small Oval/Circular | Incision required. | The newest form factor. Incision is the method to ensure proper orientation and long-term stability. EEPROM capacity is more limited compared to the Narrow flex. |
Placement Rationale:
Placement is highly subjective and dependent on individual anatomy, lifestyle, and the specific installer’s technique.
- Stability: Avoid areas with high tendon movement (e.g., directly over the wrist joint or finger knuckles) to prevent long-term mechanical stress on the PCB and solder joints.
- Geometry: The antenna alignment must match the reader. For the Narrow flex, a transverse orientation (long axis across the wrist) generally offers better coupling with standard phone antennas than a longitudinal orientation.
- Consultation: Always consult a professional installer experienced specifically with flex implants. Experience with subdermal implants generally is not sufficient, as the insertion mechanics differ significantly.
1.3 Applet stack
The flexSecure ships with a standard applet suite and supports installation of any Java Card applet via GlobalPlatformPro using the admin key you hold. No Fidesmo dependency. No marketplace.
| Applet | Capability | Notes |
|---|---|---|
| OpenPGP card 3.4 | Ed25519/X25519 on-chip. Sign, decrypt, authenticate, certify. | Private key never exportable. |
| FIDO2 / U2F | Phishing-resistant hardware security key. Origin cryptographically bound. | Works with any WebAuthn service. |
| HMAC-SHA1 | Challenge-response. YubiKey-compatible. | Used for Vaultwarden hardware unlock. |
| TOTP / OTP | Hardware-stored seed. Cannot be extracted. | Use where software TOTP seed exposure is unacceptable. |
| BIP32 wallet | HD wallet seed and signing on-chip. | Best for cold storage. |
| NDEF / NFC Sharing | Broadcasts URL without authentication. | Any NFC phone. Emergency info. |
| DuressApplet | Multi-context identity: primary/decoy/burn. PIN-gated. | Custom applet — not part of the standard DT suite. Not publicly distributed. See Section 5. |
| Custom Java Card | Any Java Card 3.1 applet via GPP. | Physical access control, key shares, custom protocols. |
1.4 flexSecure vs Apex Flex
| Factor | flexSecure | Apex Flex |
|---|---|---|
| Admin key | You hold it | Managed by Fidesmo |
| Third-party dependency | None | Fidesmo required |
| EEPROM | 167,736 bytes | 83,872 bytes |
| Custom applets | Any Java Card applet via GPP | Fidesmo marketplace only |
| Bricking risk | Real — wrong master key attempts = permanent brick | Low |
| Sovereign fit | You control all key material | Managed service in your body |
A managed dependency in software is one risk profile. A managed dependency implanted in your body, where the exit option is a second surgical procedure, is a different one entirely.
1.5 Test card requirement
Order the J3R180 before ordering the implant
The J3R180 is the same NXP P71 chip in a contact card form factor (~€20). Order from Dangerous Things
Run the entire GPP setup workflow on it at least twice before the implant procedure. Master key rotation is irreversible. Too many wrong attempts permanently bricks the chip. No recovery path.
1.6 Reader
The ACR1252U is the recommended desktop reader. Preferred over the ACR122U, which conflicts with Linux kernel NFC modules, requiring manual blacklisting. Available from Dangerous Things. Stays on the desk permanently.
2. Placement
It’s wholly up to the Practitioner to decide install location, however there are recommended places pending on the size and shape of the implant, this is my own personal position. Right wrist, dorsal surface, outer (ulnar) edge, transverse orientation, above the watch line.
Transverse orientation places the long axis across the wrist, within the stable tissue zone between tendons. Longitudinal placement crosses multiple tendon channels as they diverge toward the forearm, creating long-term mechanical stress on the PCB.
| Zone | Recommendation | Reason |
|---|---|---|
| Right wrist, dorsal, outer ulnar edge, transverse, above watch line | Correct | Stable tissue. Off central tendons. Good NFC geometry. |
| Mid-forearm above wrist zone | Avoid | Two muscle groups diverge here — PCB stress. |
| Over central extensor tendons | Avoid | High movement during wrist flexion/extension. |
| Longitudinal orientation | Avoid | Bridges tendon channels. Mechanical stress over time. |
| Wrist crease and below | Avoid | High nerve/tendon density. |
> Installer requirement
Flex implant experience is mandatory. Incision technique, not needle punch. The Dangerous Things forum maintains an installer map with verified flex practitioners.
Brief the installer explicitly: outer ulnar edge, above watch line, transverse orientation.
3. What Can It Do For You Today
All entries below are deployable with existing hardware and applets. Entries marked “Reference implementation” use code produced alongside architecture work and is not publicly distributed.
| Capability | What it means in practice | Status |
|---|---|---|
| Hardware-bound SSH | Every SSH connection requires the chip within 1–3cm. Compromised host cannot authenticate — key never touches disk. | Ready now |
| Phishing-resistant FIDO2 | WebAuthn assertion includes origin domain cryptographically. Fake login page cannot replay a valid assertion. | Ready now |
| Hardware-locked credential store | Vaultwarden unlock requires master password AND chip. Neither alone is sufficient. | Ready now |
| GPG signing and encryption | Email, document, git commit signing on-chip. Private key never leaves the secure element. eIDAS-compliant. | Ready now |
| Emergency medical info | NDEF broadcasts URL to any NFC phone without authentication or app. | Ready now |
| Physical access control | P71 can emulate NFC card profiles via custom applets. Smart locks and Home Assistant. | Ready now — custom applet required |
| Hardware TOTP | Seed on-chip, cannot be extracted. Worth using where software TOTP seed exposure is unacceptable. | Ready now |
| Continuous session auth | Daemon issues periodic challenges. Chip absent = screen locks, SSH terminates. | Reference implementation — restricted |
| Coercion-aware authentication | Secondary PIN activates decoy identity — valid, plausible, low-value. Forced auth discloses decoy only. | Applet restricted — see Section 5 |
| Behavioural anomaly detection | Daemon monitors typing and activity patterns. Deviation triggers session degradation independently. | Reference implementation — restricted |
| Hardware-attested signing | Key ceremonies and legal documents create auditable chain of custody tied to a non-extractable device. | Ready now |
| Threshold signing (M-of-N) | Implant holds one non-extractable share. Remote compromise of all other shares is insufficient. | Ready now — requires FROST |
| Cryptocurrency cold storage | BIP32 seed and signing on-chip. Seed never leaves the secure element. | Ready now |
4. Setup Sequence
4.1 Prerequisites
# System packages
sudo apt install openjdk-17-jre pcscd pcsc-tools opensc openssl python3-pip
pip install pyscard
# GlobalPlatformPro — download gp.jar from official releases, verify SHA256
# github.com/martinpaljak/GlobalPlatformPro/releases
pcsc_scan # Verify reader is detected and chip recognised
Sections 4.2 onwards cover GlobalPlatformPro administration, applet installation, and chip configuration. These operations can permanently brick the chip if done incorrectly. Run every step on the J3R180 test card before touching the implant. If you are only here for FIDO2 or basic GPG, you can stop at Section 4.1.
4.2 GlobalPlatformPro — run on J3R180 first
Step 3 permanently changes the admin key. Store the new key in your password manager before executing.
# Step 1 — verify connection (safe, no auth required)
java -jar gp.jar --info
# Expected: ISD AID A000000151000000 status OP_READY
# Step 2 — generate new admin key and store it NOW
NEW_KEY=$(openssl rand -hex 16)
# Step 3 — rotate from factory default (publicly known)
java -jar gp.jar --key 404142434445464748494A4B4C4D4E4F \
--unlock --new-key $NEW_KEY
# Step 4 — verify new key works
java -jar gp.jar --key $NEW_KEY --list
# Step 5 — install OpenPGP applet (verify SHA256 of CAP file first)
java -jar gp.jar --key $NEW_KEY \
--install SmartPGPApplet-default.cap \
--create D276000124010304C0FE000000010000
# Step 6 — clear key from environment
unset NEW_KEY && history -c
4.3 GPG key hierarchy
The master key lives on-chip and certifies subkeys only. If a subkey is compromised, revoke it without touching the master.
Master key (Ed25519) — CERTIFY ONLY — stored on flexSecure
|
+-- Signing subkey (Ed25519) — email, git commits, documents
+-- Encryption subkey (X25519) — decrypt inbound mail, files
+-- Auth subkey (Ed25519) — SSH authentication
Subkeys: 12–24 month expiry. Master key: no expiry required.
gpg --card-edit
admin # enable admin commands
passwd # user PIN: 123456 -> yours | admin PIN: 12345678 -> yours
generate # generate Ed25519/X25519 keys ON-CHIP — never touches disk
quit
echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent
ssh-add -L # verify: pubkey with comment cardno:XXXXXXXX
# Git commit signing
git config --global gpg.format ssh
git config --global user.signingkey "$(ssh-add -L | head -1)"
git config --global commit.gpgsign true
gpg --keyserver keys.openpgp.org --send-keys YOUR_KEY_ID
4.4 FIDO2 registration order
| Priority | Account type | Rationale |
|---|---|---|
| 1 | Email provider | Controls password reset for all other accounts |
| 2 | DNS provider | Controls domain — cascades to all services |
| 3 | Infrastructure consoles | Lateral movement to production systems |
| 4 | Identity provider | Cascades to all services behind it |
| 5 | Code repositories | Supply chain attack surface |
| 6 | All other services | Register backup FIDO2 key as secondary on each |
> Register a backup FIDO2 key on every service
The flexSecure is NFC-only. Register a backup FIDO2 key (YubiKey 5 NFC or J3R180) as secondary. If the implant is unavailable, you need a recovery path that does not require surgery.
4.5 HMAC unlock — Vaultwarden
ykman otp chalresp --generate 2
# Store the slot secret in your password manager before continuing
# In Vaultwarden: Settings > Security > Two-step Login > YubiKey OTP Security Key
# Test unlock before relying on it
5. Duress Framework
> Conditional control
Relevant only when: (1) an adversary has physical access or coercive leverage; (2) you may be forced to authenticate; (3) the system cannot distinguish voluntary from coerced authentication.
5.1 What the DuressApplet is and is not
A hardware-enforced context switch. Single AID, uniform external interface. An observer cannot determine which context is active from the command set, response format, or timing. The PIN (equal length across all contexts) determines which key material is active. The applet is not publicly distributed.
| The DuressApplet does | The DuressApplet does not do |
|---|---|
| Store multiple keys in strictly isolated contexts | Create decoy accounts or populate them |
| Guarantee decoy PIN only activates decoy context | Switch SSH keys or GPG agents automatically |
| Prevent timing attacks from revealing active context | Protect you if you access primary assets in decoy mode |
| Decrement all retry counters on mismatch | Make a decoy believable if accounts are empty |
Hardware guarantees context isolation. The decoy environment still requires: a dedicated account with realistic activity history, an isolated network segment, and a context-aware daemon that switches SSH keys and GPG agents on context ID.
5.2 Context model
| Context | PIN | Contents | Use case |
|---|---|---|---|
| Context 0 — primary | Primary PIN | Real keys. Full access. | Normal daily operation |
| Context 1 — decoy | Decoy PIN | Valid low-value accounts. Plausible history. No path to primary. | Coercion / forced authentication |
| Context 2 — burn | Burn PIN | Minimal. Disposable. | High-risk environments |
5.3 APDU reference
| INS | Code | Function | Auth |
|---|---|---|---|
| INS_SELECT_CONTEXT | 0x20 | Authenticate by PIN, activate context. All retry counters decrement on mismatch — constant-time. | None |
| INS_GET_CONTEXT_ID | 0x21 | Return active context ID. 0xFF if none selected. | None |
| INS_CHALLENGE | 0x30 | HMAC-SHA256 using active context key. Input: 1–64 bytes. Output: 32-byte HMAC. | Context selected |
| INS_SET_KEY | 0x40 | Set 32-byte key for context. | Admin or matching context |
| INS_SET_PIN | 0x41 | Set 4-byte PIN for context. | Admin or matching context |
| INS_RESET_CONTEXT | 0x42 | Wipe and reinitialise context with random data. | Admin only |
| INS_ADMIN_AUTH | 0x60 | Authenticate as admin (32-byte key). Session-scoped. | Admin key |
| INS_VERSION | 0xFF | Return applet version. | None |
Status words: 9000 = Success · 6982 = PIN incorrect (all counters decremented) · 6983 = Context blocked · 6985 = No context selected · 6700 = Wrong length
6. Key Lifecycle
| Key / credential | Rotation cadence | Trigger events |
|---|---|---|
| GPG subkeys | 12–24 months | Subkey expiry, suspected compromise, role change |
| HMAC secrets | 6–12 months | Suspected exposure, password manager migration |
| FIDO2 credentials | Annually on critical services | Service compromise, device replacement |
| GPP admin key | On confirmed compromise only | Triggers full reprovisioning |
| Threshold key shares | On participant change | Departure, compromise, or implant loss |
Master key — no expiry
Subkeys carry expiry dates to force rotation. The master key does not expire. Its only function is to certify subkeys, an infrequent and deliberate action. Protected by the EAL6+ secure element, not by expiry.
Master key backup
> The on-chip master key cannot be exported — by design
Backup strategy: maintain a backup FIDO2 key; maintain GPG revocation certificates in encrypted offline storage; maintain the GPP admin key for replacement chip configuration.
On chip loss: publish revocation, acquire replacement, generate new master key, re-sign subkeys.
Decommissioning
Revoke all GPG subkeys and publish revocation certificates. Deregister all FIDO2 credentials. Rotate all HMAC secrets. Update SSH authorized_keys. The on-chip master key cannot be erased by command. The chip must be physically destroyed or permanently blocked via GPP. Document and sign the decommission event before destruction.
7. Audit
The audit chain provides integrity of record, not proof of voluntary action. A signed log proves it was not tampered with after creation. It does not prove the conditions under which each entry was created. This gap is irreducible.
| Operation | What to log | Destination |
|---|---|---|
| SSH authentication | Timestamp, source IP, server fingerprint, key fingerprint | Server SSH log + personal audit trail |
| GPG signing | Timestamp, document hash, key fingerprint, context ID | GPG agent log + personal audit trail |
| FIDO2 authentication | Timestamp, relying party, success/failure | IdP logs + personal audit trail |
| HMAC challenge-response | Timestamp, requesting service, response status | Vaultwarden audit log |
| Presence verification | Timestamp, challenge result, session state change | Daemon log |
| Context switch | Timestamp, context ID, action taken | Daemon log — logged under active context |
| Threshold signing | Timestamp, participants, document hash, ceremony ID | Ceremony log — all participants sign |
> External anchoring
“Stored separately” must mean a genuinely independent store: remote append-only storage (WORM policy), WORM media, or RFC 3161 trusted timestamping. A co-located log store that a compromised endpoint can also reach is not separate.
8. Recovery
Run through chip-loss recovery on the J3R180 before the implant goes in. A backup that has never been tested is a belief, not a backup.
Backup Strategy (Dual-Flash):
Simply registering a YubiKey as a secondary FIDO2 authenticator is insufficient for a true hardware root of trust. To create a seamless, drop-in replacement for the implant in the event of damage or loss:
- Air-Gapped Generation: Generate your GPG master and subkeys on a completely offline computer (air-gapped).
- Dual Flashing:
- Flash the exact same private subkeys to the FlexSecure (via GPP/OpenPGP).
- Flash the exact same private subkeys to a YubiKey 5 NFC (via
ykmanor GPP).
- Result: Both devices now hold the identical private key material.
- Scenario: If your implant is damaged or lost, you simply pick up the YubiKey.
- Outcome: The server sees the same key fingerprint. No certificate re-issuance, no key rotation, and no downtime are required. The YubiKey acts as a true “hot-swap” backup.
- Storage: Store the YubiKey in a fireproof safe or safe deposit box (cold storage).
Note: This requires the YubiKey to support the OpenPGP applet (YubiKey 5 Series does). This strategy ensures that your identity anchor is not a single point of failure, even if the body-bound device is compromised.
| Item | Backup | Recovery action |
|---|---|---|
| GPG private key | Not backed up — non-exportable by design | Revoke subkeys. Generate new master key on replacement chip. |
| GPG revocation certs | Encrypted offline storage + password manager | Publish immediately on chip loss. |
| HMAC slot secret | Password manager | Re-configure HMAC slot on replacement chip. |
| FIDO2 registrations | Backup FIDO2 key registered as secondary on all services | Use backup key. Re-register implant when replacement available. |
| GPP admin key | Password manager + encrypted offline storage | Required to configure any replacement chip. |
| Threshold key shares | Co-signers hold remaining shares | Coordinate share rotation. New chip rejoins threshold ceremony. |
Recovery sequence — chip loss
- Revoke GPG subkeys. Publish revocation certificates to keys.openpgp.org immediately.
- Deregister FIDO2 from all services using the backup FIDO2 key.
- Update SSH authorized_keys on all servers.
- Rotate HMAC secrets. Reconfigure Vaultwarden unlock.
- Notify threshold co-signers. Coordinate share rotation.
- Acquire replacement chip. Run J3R180 verification workflow before provisioning.
- Provision replacement implant — full setup sequence from Section 4.
- Re-register FIDO2 on all services.
- Return backup FIDO2 key to secondary status.
- Rejoin threshold signing with new share via DKG ceremony.
9. Failure Mode Reference
| Failure mode | Attacker gains | Detection | Response |
|---|---|---|---|
| GPP admin key exposed | Full chip administration | Unexpected applet changes | Rotate key. Revoke all credentials. Provision replacement. |
| GPG subkey compromised | Forged signatures attributable to you | Unexpected signatures in audit log | Revoke subkey. Publish revocation cert. Master key unaffected. |
| HMAC secret leaked | Credential store without chip | Unexpected access events | Rotate HMAC secret. Reprogram slot. |
| FIDO2 relay attempt | Authentication bypass | Origin check fails — service rejects | FIDO2 origin binding defeats relay. Monitor logs. |
| Coercion — forced tap | Forced auth — primary or decoy | Behavioural anomaly; duress activated | Duress framework (Section 5). |
| Chip read failure | Reduced availability | Intermittent presence check failures | Backup hardware key. Monitor. Plan replacement. |
| Audit log tampered | False event narrative | Hash chain mismatch vs external anchor | External anchor proves tampering. Investigate window. |
| Endpoint compromise post-auth | Abuse of authenticated session | Behavioural anomaly | Tokens are short-lived. Rotate. Review audit log. |
| Wrong PIN under stress | Primary identity exposed | None — indistinguishable | Prevention only: rehearse decoy workflow until automatic. |
10. Kit and Resources
Hardware
| Item | Source |
|---|---|
| VivoKey flexSecure | dangerousthings.com/product/flexsecure/ |
| J3R180 test card | dangerousthings.com/product/j3r180/ — order this first |
| ACR1252U NFC reader | dangerousthings.com/product/acr1252u-usb-nfc-reader-writer/ |
Software
| Tool | Location | Purpose |
|---|---|---|
| GlobalPlatformPro | GitHub - martinpaljak/GlobalPlatformPro: Manage applets and keys on JavaCard-s like a pro 🌐 🔐 · GitHub | Applet installation and chip management |
| flexSecure applets | GitHub - DangerousThings/flexsecure-applets: Collection of JavaCard applets for the FlexSecure, as well as build and testing scripts, and documentation. · GitHub | Official applet distribution |
| FROST | GitHub - ZcashFoundation/frost: Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation · GitHub | Threshold signature implementation |
| Open Quantum Safe | openquantumsafe.org | Post-quantum primitives |
| FreeTSA | freetsa.org | Free RFC 3161 trusted timestamping |
| Authentik | goauthentik.io | Open-source identity provider |
| Headscale | GitHub - juanfont/headscale: An open source, self-hosted implementation of the Tailscale control server · GitHub | Self-hosted ZTNA |
Community resources
| Thread | URL |
|---|---|
| flexSecure vs Apex Flex | Choosing the top-tier implant: Apex Flex or FlexSecure? |
| Flex placement positions | Flex DF2 and Flexsecure Java Card positions |
| flexSecure basics / applet install | flexSecure Java Card basics / app install |
| Implant location naming | Naming convention for implant locations in the hand - #2 by Pilgrimsmaster |
| EU installer map | forum.dangerousthings.com |
VivoKey flexSecure · Practical Reference · April 2026 · Not affiliated with Dangerous Things or VivoKey.