HARDWARE EVIDENCE↗
0/4Four physical tag slots
SECURITY ENGINEERING / FIELD OPERATIONS GX / 002
⊕ GHOSTKEY ADVERSARY ASSURANCE SYSTEM LAB BUILD 2.0
Every signal
has a story.
Trace the credential. Challenge the trust boundary. Prove what the evidence can—and cannot—establish.
00 real lock tests07 modeled threatsOFFLINE / READ-ONLY BY DEFAULT
ACCESS TRUST TOPOLOGYCONCEPT MODEL / NOT LIVE TELEMETRY
NFC METADATA POLICY RULES LOG EVIDENCETOPO // 001
P0 / PHYSICAL DEVICE PILOT
Start 4-tag field test ↗Three white cards + one blue fob.
Open the phone-ready field page to inspect, write public NDEF test records when safe, verify read-back, and export honest evidence. Real passkey and USB recovery remain separate gates.
OPERATIONAL PICTUREREAL DATA IS LABELED / UNVERIFIED IS VISIBLE
THREAT VALIDATION⌁
0/7Synthetic scenario runs
DOOR INTELLIGENCE◫
0Imported or simulated events
PHYSICAL VALIDATION—
0Controlled lock tests to date
FIELD WORKFLOWS CHOOSE YOUR NEXT OPERATION
ENGAGEMENT GOVERNANCE ROE / 01
⌁
Rules of engagementRequired for physical NFC operations
POLICY / AHard boundary. No active hotel-key duplication, lock bypass, protected-sector extraction, or live-door command sequences.
PROVENANCE / WHAT WE ACTUALLY KNOW
Keep observation separate from interpretation.
OBSERVEDMIFARE Classic 1KOne white card + blue fob from earlier NFC Tools screenshots
NOT PROVENDoor authorizationNone connected
0%
OPERATION 02 / PASSIVE NFC TELEMETRY
The signal
workbench.
Tag discovery, reader-reported identity evidence, and controlled benign duplication. Every result is graded by what was actually measured.
AVAILABLE DEVICE SLOTSSELECT ONE TO ACQUIRE
◈
NFC / 13.56 MHz
SCANNER / PASSIVE READ
Choose a test device
Select a device. Use Chrome on Android with NFC enabled.
Unverified read detected
Device responded without a reader-reported identifier. This cannot prove the selected card was the source.
CLASSIFY / NFC TOOLS
Hardware fingerprint
For chips unsupported by Web NFC, enter the public technology from NFC Tools READ.
REPLAY / PAST EVIDENCE
Import existing scan
Bring your existing four-card JSON back into the analysis. Not a new live hardware scan.
EXPERIMENT 002 / LEGITIMATE REFERENCE CARD
ACTIVE CREDENTIAL — READ ONLYIHG hotel-card fingerprint
Record public NFC technology and NDEF record types from the card you legitimately hold. This is separate from the four blank test devices. No payloads, serial values, protected sectors or hotel access secrets are retained.
▤HOTEL / REF-01NOT ASSESSED
Use Chrome on Android. Scan only the legitimate card you hold, with no hotel identifiers recorded.
An active hotel access credential is NOT a cloning target. If Web NFC cannot read its NDEF, record the chip family from NFC Tools READ without accessing protected data.
EXPERIMENT 001 / NON-ACCESS NDEF
Controlled content replication
Write an identical, harmless demonstration message to each confirmed blank white card. This tests application-message copying—not credential cloning.
FIXED, NON-SECRET PAYLOAD
CPX-GHOSTKEY-LAB-NONACCESS-2026-10-31Only blank owned white cards. Never use a live hotel credential.
OPERATION 03 / DETECTION VALIDATION
Adversary
simulation.
Challenge security assumptions using reproducible threat fixtures. Run each scenario individually or execute the full battery. No real lock is contacted.
No simulations run. No physical lock connected.
THREAT SCENARIO MATRIXRED = RISK / GREEN = SYNTHETIC DETECTION / AMBER = UNPROVEN
OPERATION 04 / EVENT INTELLIGENCE
Read the trail.
Question the trail.
Cross-correlate authorization, revocation, and access anomalies. Lock event history must come from an authorized vendor export; the phone cannot extract it by tapping a door.
LOCK-SIDE PROFILE
Reader system
Reader-side metadata only. No door firmware, keys, RF exchanges, or entry history are retrieved from NFC browser scans.
EVENT INGEST
Source verification
Import a permissioned, anonymized event file—or run the clearly labeled synthetic dataset.
No verified door audit events are connected.
FIELD PASS / OBSERVED NORMAL USE
SELF-REPORTED / NOT AUDIT-PROVENDocument the door, not an invented exploit
Record a normal entry attempt to your assigned room using your legitimately issued hotel card. Do not try blank cards, the blue fob, copied keys, or unauthorized doors.
No physical access observation logged. A normal door response is not a vendor-authenticated audit event.
IHG card: not characterized · Lock protocol: unknown · Vendor audit: not supplied.
FINDINGS / EVENT CORRELATION
NO REAL LOCK EVENTSAudit anomalies
No events yet. Import authorized data or run the synthetic demo.
OPERATION 05 / IDENTITY ASSURANCE ARCHITECTURE
Trust nothing.
Verify every gate.
Protect privileged access with a verified password, a USB FIDO2 key, and a second cryptographic NFC authenticator—then monitor anomalous activity and protect encrypted recovery copies. This is a policy simulation; no production session can be issued here.
CRITICAL AUTHENTICATOR RULEThree checks are not automatically three independent factors: password = knowledge; USB + NFC = two possession authenticators. Your standard flash drive and MIFARE Classic 1K cards cannot provide the required FIDO2 proofs.
01 / KNOWLEDGE
Verified password
Argon2id/PBKDF2 policy at server verifier. No password entered or stored here.
SERVER VERIFIED ONLY→
02 / USB
FIDO2 security key
Origin-bound WebAuthn, challenge signature, and hardware user verification.
CRYPTOGRAPHIC PROOF→
03 / NFC
Independent NFC key
Second separately enrolled FIDO2 authenticator for privileged actions.
NO UID / CLASSIC AUTH→
04 / POLICY
Transaction gate
Fresh signed challenge, verified origin, risk decision, and bounded session.
DENY ON INCOMPLETE PROOF
SECURITY POLICY / CONTROLLED SIMULATOR
Run an authentication decision
The simulation generates synthetic server-backed proofs. It does not unlock an account, enroll an authenticator, or send a password to the browser.
No scenario run. Actual authentication remains unconfigured.
Real policy enforcement requires a server-side WebAuthn verifier that checks RP ID, origin, signature, user verification, challenge reuse, credential enrollment, and transaction binding. It cannot be enforced by a decorative browser checkbox.
AUTHENTICATOR COMPATIBILITY
Check your device environment
Detect browser API support without triggering enrollment or revealing credential data. This is not proof that any hardware key is connected.
Not checked. A browser that supports WebAuthn still needs registered FIDO2 hardware and a server verifier.
SESSION RESPONSEContainment design
0–29Normal policy checksOnly permit after all cryptographic assertions verify
30–59Step-up and reviewRequire independent reauthentication and analyst triage
60–100Hold privileged operationFlag risk, propose session revocation and verify incident evidence
A browser cannot monitor all device traffic. Live telemetry requires an endpoint agent, authenticated gateway/WAF events, and server-side anomaly detection.
EXPERIMENT 003 / OWNER-CONTROLLED HARDWARE
PUBLIC IDENTIFIER · NOT MFAProvision a real NFC card or blue fob.
Write a random public tag reference to a verified blank, writable CPX-owned card/fob. Assign a secondary or tertiary routing role. This never writes a password, secret, master key, access token or FIDO credential.
TAG / 01
Create and write
PUBLIC NFC TEXT / NOT A SECRET
No reference generatedGenerate the public reference first. If the fob is not NDEF-writable, use a compatible blank tag; never force sector formatting.
Read-back not performed. A matching public payload is not authentication and can be copied.
CROSS-DEVICE / 02
Bridge verification request
Generate an expiring, public approval intent that a future trusted phone companion can display and authorize. A remote verifier must validate a separately enrolled cryptographic signature or WebAuthn assertion before issuing any session.
90-SECOND INTENT / PUBLIC DEMO DATA
No request generatedNo remote server, trusted device pairing, or transport is connected. Copying this intent never authorizes an action.
01 · TAG ROUTING02 · VERIFIED DEVICE03 · SIGNED CHALLENGE04 · SERVER GRANT
Anti-relay boundary: device-bound proof, RP/origin binding, single-use challenge, transaction details, short expiry, and deliberate user approval. The generic blue fob cannot securely measure proximity, resist cloning, or relay raw door-lock commands.
ENCRYPTED VAULT / USB / REMOTE RECOVERY
DESIGN CHECKLIST · NOT VERIFIEDBackup without exposing the keys.
Keep password-vault ciphertext on an encrypted USB volume and in remote storage, with independent offline recovery material. Do not put plaintext passwords, recovery codes, or master keys onto NFC tags or this page.
LOCAL VAULTClient-side encryption / supported vault app
→
USB COPYEncrypted removable storage
+
REMOTE COPYCiphertext-only object storage
+
OFFLINE RECOVERYIndependent secure location
Unverified design checklist. GHOSTkey does not currently encrypt, upload, restore, or inspect your password vault.
Encrypted KDBX copy utility: node scripts/ghostkey/vault-mirror.mjs <vault.kdbx> <USB folder> <cloud-sync folder>. Run only on a trusted laptop with an already-encrypted vault. The browser does not transfer passwords or backups.
OPERATION 05 / EXAMINATION REPORT
Evidence over
assumption.
Independent observed facts, simulated threat fixtures, audit gaps, and defensible recommendations. Never claim a working attack from absent evidence.
PROVENANCE MATRIX
What can we substantiate?
REMEDIATION PRIORITY