If the master key is stored in iOS, then the app you provided can only allow the phone user to use their own card, correct?
a quick update:
product landing page - close to finish line …
hi Everyone,
Quick Update:
The ChipVault v2.0 just went Live on the App Store — wanted to circle back here first since this thread was where a lot of the early idea sharing had happened.
What’s New in ChipVault v2.0:
• Self-Manifesto — every personalized card carries its own encrypted on-chip recovery record. Get a new iPhone, install ChipVault, tap any of your cards, enter the master password, the vault rebuilds itself. No cloud account, no backup file, no support ticket. The card is the source of truth.
• Sync to Card — edit entries on the phone, write changes back with one NFC tap. Session keys re-derived per sync.
• Edit Card without NFC — rename, retheme, change icon, swipe-delete categories: all metadata-only, instant, no tap needed.
• Reset & Restructure — recovery path for the rare DESFire allocator-stuck case after many delete/add cycles. Rebuilds the chip with your existing category set; user data wipes (back up first).
• Visual storage donut — per-byte allocation map across categories, system overhead, and free space. Secure Messaging end-to-end. No third-party crypto.
App Store: ChipVault App - App Store
Product Landing page + a rudimentary walkthrough video: ChipVault · Data Secured. On your Card. In your Pocket. I am working on a more elaborate video to share shortly.
Genuinely curious what folks here have for feedback. Reply or DM — I’ll read everything.
/ Nagi
6 Likes
I would love to have an android version, looks very good and clean.
2 Likes
If I get enough requests for android app, I can think of prioritizing and bumping up the roadmap and timeline.
Who can help with collating requests please.
Thanks
1 Like
I’m glad to hear ChipVault is gaining your liking and its usefulness.
Would appreciate your app ratings and reviews. Helps us during such early phase. Thanks
I just gave it a test, and it’s great.
However, there are a few things i would like:
- Ability to have a public NDEF Record on the chip, so it can still be scanned by normal phones to open a link for example.
- Ability to backup to a smaller card of used space allows it, maybe just single categories
- Documentation on how the keys are derived.
I don’t want to steal your app, but if it is no longer available for whatever reason on the AppStore, all data on the cards is lost permanently, no matter how many backups you have.
Being able to derive the keys yourself would allow to create something to extract stored data from the chip.
1 Like
The first two asks are on the roadmap, but, not high priority.
As far as documentation for keygen logic, At the moment no- plans for publicly sharing that logic for security reasons.
I’m not exactly a fan of “security through obscurity”.
Knowing how the keys are derived from the password should not have any impact on security as long as the password is secret.
If that is not the case, the implementation ist at least questionable.
Using a standard function like PBKDF2 with the password and card-ID + maybe category as input should tick all boxes needed from a security perspective.
Considering the need for card presence and the time needed to test a single key, even something simple like SHA256(Password+CardID+Category) with a few rounds should be sufficient a brute forcing is not practicable
4 Likes
I’ll make a Poll.
3 Likes
Thank you @Pilgrimsmaster - much appreciated.
1 Like
You’re raising a fair point and I want to address it properly rather
than deflect.
You’re right that Kerckhoffs’s principle applies — security shouldn’t
depend on obscurity, and a sound KDF should be safe to document. My
hesitation isn’t about hiding a weak design; it’s about not giving
attackers a step-by-step guide to a specific implementation. There’s
a meaningful difference between publishing the principle (which we
should do better) and publishing the recipe (which we’d rather not).
We’ve updated the FAQ on the product page to document the cryptographic
posture at a high level — primitives, key derivation inputs, why the
master password is the only secret, key separation across categories,
etc.
We’ve also added an explicit commitment: if ChipVault is ever
removed from the App Store for any reason, we’ll publish a standalone
Recovery Tool that can decrypt cards given the master password. Your
data shouldn’t be locked away because of something outside your control.
FAQ: ChipVault · Data Secured. On your Card. In your Pocket.
Thanks for the discussion — it’s making the product better.
2 Likes
Quick update for anyone following the project.
ChipVault 2.0.1 just shipped to the App Store.
What’s new in this release:
- Bidirectional backup linkage — when you back a card up to another, the destination’s on-chip Self-Manifesto now records the source card’s UID. Opens the door to “where did this card’s data come from” diagnostics without external state.
- Edit Card flow improvements: unsaved-changes confirmation, commit-after-success ordering for the Sync to Card NFC ceremony.
- Launch splash, native iOS rating prompt after successful backups, misc UI polish.
Quick reminder of what ChipVault does: turns blank NXP DESFire EV2/EV3 NFC cards into hardware-backed personal vaults. AES-128 encrypted at the chip level, secured by a master password derived per-card. No cloud, no servers, no accounts.
Landing page (includes demo video + full feature list):
App Store:
https://apps.apple.com/us/app/chipvault/id6772799276
Happy to answer questions on the implementation approach, NXP card sourcing, or anything else technical.
1 Like