DESKTOP HELPER ยท v1.0.0

ELAI chip-helper

A small local bridge that lets the ELAI ledger console and verifythecard.com talk to your USB chip card reader on desktop. Required because modern operating systems claim chip readers exclusively for the system smart-card framework, blocking browser-based WebUSB access. The helper uses the same framework as an API instead of fighting it.

๐ŸŽ
macOS
โœ“ Ready
๐ŸชŸ
Windows
soon
๐Ÿง
Linux
soon
๐Ÿ“ฑ
Mobile
use OuiAmi app
Why install something? Chip cards are physical โ€” they sit in a USB reader plugged into your computer. Cloud sandboxes can't access your USB. Browser WebUSB conflicts with the OS smart-card claim on Mac, Windows, and Linux. The helper is the only clean path on desktop. On mobile, use the OuiAmi App Store / Play Store app instead โ€” it uses native NFC, no install needed beyond the app itself.

โœ“ What actually gets installed

Full disclosure โ€” here's exactly what the installer does to your Mac:

  • One Python file at ~/Library/Application Support/ELAI/chip-helper.py (~18 KB, plain text โ€” read it)
  • One launchd plist at ~/Library/LaunchAgents/com.americafirst4us.elai-chip-helper.plist โ€” registers the helper as a background service that starts at login
  • Two log files at ~/Library/Logs/elai-chip-helper.{log,err} โ€” for debugging

Network: The helper opens localhost:8001 โ€” only reachable from your own machine. It accepts cross-origin requests from americafirst4us.com, verifythecard.com, idregulators.com, 4pdfs.com, and localhost only. No outbound network calls. No telemetry.

Permissions: User-level only. No sudo, no system-wide changes, no kernel extensions. Removal is one command: ./uninstall-mac.sh.

๐Ÿ‘ Eyes only ยท what the helper can and cannot do

Honest threat model. If you're going to install something on your machine, you deserve to know exactly what its attack surface looks like.

โœ“ What the chip and the helper together refuse to give up โ€” even if you ask nicely:

  • Your card's private key โ€” never leaves the chip itself. The secure element refuses to expose it.
  • Your PAN (card number) โ€” INTERNAL AUTHENTICATE doesn't return account data.
  • Your cardholder name โ€” not in SELECT or AUTH responses.
  • Any signature from a civilian card โ€” chip refuses INTERNAL AUTHENTICATE outside a full payment transaction (you'll see 6985 or 6D00 โ€” that's a polite refusal, by design).
  • Any data over the network โ€” the helper makes zero outbound calls. No telemetry. Watch with lsof -i if you want to verify.

โš  What a successful attacker on your machine could observe:

  • Which card is currently in your reader (the AID family โ€” Visa / Mastercard / PIV / CAC โ€” and the ATR fingerprint).
  • When you inserted it (timing).
  • How many different cards you cycle through in a session.

๐Ÿ›ก How we defend against drive-by attacks:

  • Localhost-only binding (127.0.0.1:8001) โ€” no remote attacker can reach it. Your home network can't either.
  • CORS allowlist โ€” only americafirst4us.com, verifythecard.com, idregulators.com, 4pdfs.com, and localhost can read responses. A random site that loads in another tab gets blocked.
  • Plain Python source you can read โ€” under 500 lines. Open it before you trust it.

๐Ÿ”ง Known limits โ€” what we'll harden before broad release:

  • CSRF via "simple request" POST โ€” a hostile site can fire a POST that triggers the helper to read your card. They can't read the result (CORS blocks that), but the card gets polled. Mitigation in progress: per-origin auth token + optional native OS confirmation prompt on every /chip-event.
  • Browser extensions bypass CORS entirely. Only install extensions you trust. The Chrome MV3 extension we're building for verifythecard will eliminate the localhost port altogether (uses native messaging โ€” a tab-scoped pipe Chrome itself manages).
  • If a website you trust (americafirst4us.com, verifythecard.com, etc.) gets XSS'd, that XSS inherits full helper access. We protect those origins like the trust roots they are.

Bottom line: for current personal + early-user use, the surface is small and your chip itself protects what actually matters. For broader public deployment, the browser extension is the right architecture.

1 Download for macOS

2 Install Python & pyscard (one time)

The helper is a Python script. Easiest path on macOS uses Homebrew:

brew install python
python3 -m pip install --break-system-packages pyscard

If you don't have Homebrew: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

3 Run the installer

In Terminal, navigate to where you saved the files and run:

chmod +x install-mac.sh
./install-mac.sh

The installer detects your Python, copies the helper to ~/Library/Application Support/ELAI/, registers it as a macOS LaunchAgent, and starts it. From this point on, the helper auto-starts every time you log in and auto-restarts if it crashes. No terminal window required.

4 Verify it's running

In any terminal:

curl http://localhost:8001/health

You should see JSON like {"ok":true,"reader":"...","atr":"..."}. With a chip card inserted, card_inserted will be true.

Now any ELAI ecosystem surface โ€” the ledger console, chip-bind.html, future browser extensions โ€” can enroll chip cards on your Mac.

5 Uninstall (anytime)

./uninstall-mac.sh

Unloads the LaunchAgent, removes the plist, optionally removes the installed script. Log files in ~/Library/Logs/elai-chip-helper.{log,err} are left alone.

verifythecard.com ยท Try the PoC ยท Ledger Console ยท Verify a PDF
AmericaFirst4Us Inc. ยท ELAI ecosystem ยท US Patent Application 17/085,257 + CIP โ€” both pending.
Source code is the file you just downloaded โ€” open it, read it, modify it. It's a single Python file under 500 lines.