Looking for a sanity check before opening a GitHub issue on KeyOS.
I’m exploring building a Passport Prime app that would help with Bitkey multisig exit / offline recovery (or potentially, act as a dedicated secondary client aside from the Bitkey app):
Talk to a Bitkey over NFC from Prime (same idea as tapping Bitkey with the phone app — unlock, then a short back-and-forth over NFC).
Import the mobile/App key from the Emergency Exit Kit after Bitkey helps decrypt it, and keep that key wrapped on Prime.
Build and review a spend on Prime, get Bitkey’s hardware signature over NFC, add the App key signature on-device, then hand the fully signed transaction to Envoy (or another companion) to broadcast.
Goal is a sovereign exit path that doesn’t need Block’s servers: Prime as offline coordinator, Bitkey as the hardware signer, companion for broadcast.
Regarding current NFC functions:
From the public Capabilities / NfcApi docs, third-party apps mainly get NFC status, and NDEF read/write is Foundation-signed and aimed at KeyCard-style “read/write a payload on a card,” such as in the case of the recovery cards.
Bitkey’s NFC flow doesn’t seem to fit the existing APIs - I am no expert, but in the research I’ve done, the existing apis don’t seem capable of providing a back-and-forth-style conversation (ISO-DEP / APDU transceive) as implented.
So my questions for the team:
Hardware: Could Prime’s NFC hardware (reader/sender side) realistically be used to talk to a Bitkey the way a Bitkey talks to a phone?
Software / KeyOS: Is a “send command, get reply, stay in session” NFC API something you’d consider exposing (third-party or Foundation-signed)? Or is NFC intentionally limited to KeyCards + status (and FIDO when Prime is the tag)?
I’m happy to file a clear feature request on KeyOS if this is in the realm of possible and trying to figure it out. If it’s a hard no, I’ll look into doing this within an iOS app instead.
Note that I’m not a hardware / NFC expert, and even with asking AI, I wasn’t able to get a clear answer.
Thanks, this is a well-researched proposal and your reading of the current APIs is correct.
Today, a third-party Prime app cannot implement this flow. The public NFC surface does not provide a persistent ISO-DEP/APDU session with send-command/get-response functionality. NDEF read/write would not be a substitute for the protocol Bitkey uses.
The hardware does not appear to be the fundamental blocker. Prime can operate in NFC reader/poller mode, and the underlying NFC stack has data-exchange support. We would still need to validate compatibility with Bitkey end to end, including its protocol, timing and antenna behaviour.
On the KeyOS side, this would require a new API for opening an exclusive NFC session, exchanging APDUs and closing the session, with appropriate permission and user-confirmation controls. That is a reasonable feature request to file.
The rest of the design is plausible. Your app could import the decrypted Bitkey App key into its own isolated storage and wrap it using its app-specific seed. It would not need or receive access to Passport Prime’s master seed. The fully signed transaction could then be exported to a companion over QuantumLink, QR or USB. Direct Envoy support would additionally require Envoy to understand the app’s protocol.
So this is not a hard no, but the NFC transport API needs to exist before the complete app can be built. Please file the KeyOS issue around ISO-DEP/APDU transceive support and link this thread so the use case remains attached to it.
tagging @Georges to see if my agent got anything wrong here
Q’s summary of the current API surface is accurate: there is no ISO-DEP/APDU session exposed today, and NDEF read/write is not a substitute for it. I would like to temper one line of it though, the one about the hardware not being the fundamental blocker. I wrote the NFC stack on Prime, so let me give you the honest picture.
Prime’s NFC front end is a modest transceiver driven over SPI from a userspace service. There is no hardware acceleration for the protocol layer, so the framing, the timing and the state machine all run in software. In reader/poller mode that is workable, and it is how we read and write KeyCards. Card emulation, where the device has to answer a reader inside a fixed time budget, is where it becomes painful. We did get it working for FIDO, and it took a great deal of effort and tuning that I would not describe as comfortable. My realistic assessment is that adding further capability on that path ranges from problematic to impossible on this hardware.
Your flow would need the reader direction rather than emulation, which is the friendlier of the two, so it is not ruled out by physics. It is not free either:
an exclusive session API means one app takes ownership of the radio and suspends the discovery loop that currently serves FIDO and KeyCard, with all the permission and user-confirmation design that implies;
long stateful exchanges with a third-party device we cannot characterise in-house are exactly where the timing margins on this front end are thinnest, and we have very little room to widen them;
every NFC feature we have shipped has cost several times what it looked like it would from the outside.
On the current hardware this is not a good bet, and I cannot give you a date for it. The next generation of the hardware is where we are improving the NFC situation properly, and a general session/transceive API is a much better fit there than a retrofit here.
Please do still file the issue and link this thread. It is a good use case and I want it attached to the work when we plan that generation, rather than rediscovered later.
For what it is worth, the rest of your design is sound and independent of the transport. An app can hold the imported App key in its own storage, wrapped with its app-specific seed, with no access to the device master seed, and export a fully signed transaction over QuantumLink, QR or USB. If you want something working in the near term, the iOS route is the pragmatic one, and it does not close the door on a Prime app later.
Thank you @qna and @Georges for the feedback here.
For now I’ll look into seeing if maybe I can use a standalone app on iOS to do the NFC read / write while Passport Prime maybe uses camera to communicate / sign the transaction with the stored mobile key.
I’ve opened an issue on GitHub in the KeyOS repo (albeit, as I mentioned, I’m not an expert in this area - but this thread is linked - so can be referred-back to for future reference).