AirGap Vault: a crypto wallet whose private key never leaves the phone

Two devices and a one-way channel

AirGap is described as a crypto wallet system that lets you secure crypto assets with one secret on an offline device. The AirGap Vault application is installed on a dedicated device that has no connection to any network, and the AirGap Wallet is installed on your everyday smartphone.

The security concept behind air-gapped systems is to work with two physically separated devices, one of which has no connection to the outside world or any network. In this system the component with no internet connection is the AirGap Vault, and the two components communicate through one-way communication using QR codes.

The data flow is worth spelling out, because it is the whole design. The Vault is responsible for secure key generation. Accounts for multiple protocols can be created on it, and the generated secret is saved in the secure enclave of the device, only accessible by biometric authentication. The AirGap Wallet prepares a transaction and transfers it to the offline device via QR code, where it is signed and sent back to the Wallet using another QR code. The secret never leaves the Vault.

The audience is a crypto holder who wants a key that has never been on a networked device, and the price is a second phone, a camera used as the data channel, and a signing step that is deliberately inconvenient.

The app itself is a hybrid application using the same codebase for Android and iOS, and it is built on AirGap's protocol agnostic airgap-coin-lib library to interact with different protocols, plus the project's own secure storage implementation.

Key generation, and why sensor entropy is mixed in

The entropy seeder is the part of the design that gets the most attention, and the reasoning is spelled out.

The seeder uses the native secure random generator provided by the device and concatenates that with the sha3 hash of the additional entropy drawn from audio, video, touch and the accelerometer. The README gives four reasons.

First, sha3 hashing is cryptographically secure, such that the entropy of the hash of the secure random is at least the entropy of the secure random. Second, adding bytes to the sha3 function never lowers entropy but only adds to it. Third, by reusing the hash of an earlier round as a salt, the entire collected entropy of the previous round is folded in. Fourth, native secure random cannot be fully trusted, because there is no API to check the entropy pool it is using.

The algorithm in the README is short enough to read in full:

const ENTROPY_BYTE_SIZE = 256
let entropyHashHexString = null

function toHexString(array) {
  return array
    .map(function (i) {
      return ('0' + i.toString(16)).slice(-2)
    })
    .join('')
}

function seedEntropy(additionalEntropyArray) {
  const secureRandomArray = new Uint8Array(ENTROPY_BYTE_SIZE)
  window.crypto.getRandomValues(secureRandomArray)
  console.log(entropyHashHexString + toHexString(secureRandomArray) + toHexString(additionalEntropyArray))
  entropyHashHexString = sha3_256(entropyHashHexString + toHexString(secureRandomArray) + toHexString(additionalEntropyArray))
  return entropyHashHexString
}

A reviewer should note the reasoning in the README is about not lowering entropy, which is true, and the practical effect is that the hardware generator remains the foundation and the sensors can only add to it. That is a defensible position, and the sensor entropy is best understood as defence in depth rather than as the source of the randomness.

Verifiable builds and the supply chain argument

The README treats two supply chain concerns separately, and both are the kind of thing a wallet project has to answer for rather than assert.

On supply chain attacks, the argument is that in the past years multiple cryptocurrency wallets have been targeted by attackers trying to steal user funds, and one common vector is compromising a dependency used by the wallet to inject malicious code. The response described is a system that separates the dependencies used during testing and development from the dependencies used to build and run the project, which reduces the risk of malicious code injection during the build and test steps.

On verifiable builds, the property described is reproducibility, and the argument is that this matters for any open source wallet because it means an executable downloaded from the Play Store or App Store can be exactly reproduced by compiling the published source. If it cannot, that means there is hidden or removed code in the published version that is not visible in the published source.

The project points at WalletScrutiny, which examines a wide variety of cryptocurrency wallets to determine their reproducibility, and states that AirGap Vault was one of the first wallets to be marked as reproducible. That is a claim a user can check rather than take on trust, which is the point.

On audits, the application as a whole and multiple components have been audited by different third party companies, all audits have found no way of extracting the private key from AirGap Vault, and the reports will be released once all findings have been resolved. The last clause is worth noticing: at the time of writing, the reports are not public, so a reader cannot check the audit findings themselves, which is a gap next to the verifiable build claim.

Building the app from source

The build is a Capacitor and Angular project with an Electron shell, and the steps are short.

Dependencies come first:

$ npm install -g @capacitor/cli
$ npm install

To run it locally in a browser:

$ npm run start

To build and open the native project:

$ npm run build
$ npx cap sync

And once that has run, the native iOS or Android projects can be opened in XCode or Android Studio:

$ npx cap open ios
$ npx cap open android

The package manifest shows how large the toolchain is. The scripts are Angular-centric, with ng build, ng test, ng lint and ng e2e, and the build runs a signature database step first, build:signatures, which calls a node script to produce the signature data the app needs. There are separate build variants for production, for an Electron target with a relative base href, and one that removes the Sapling support before building, which tells you the protocol support is modular.

The postinstall hook is where the pinning happens, and it is unusual enough to be worth naming. It runs jetifier, then applies diagnostic modules, patches dependency versions, fixes a qrscanner Gradle issue, and copies builtin modules. In plain terms, the build repairs and pins parts of the dependency tree so that the resulting binary matches what the reproducible build claim requires.

Translations are handled through Transifex, with each language living in an i18n json file under src/assets/i18n.

Where AirGap Vault is the wrong tool

The first limitation is the two-device operational model, and it is not a small one. You carry one phone for signing and one for everyday use, and every transaction becomes a camera-to-camera exchange. A user who makes several transactions a day will feel that, and the friction is not a design oversight, it is the security model.

The second limitation is the split state. Because the Vault holds the secret and the Wallet holds the account view, neither device has the whole picture, and a user who loses the Vault's seed phrase or replaces that phone has a problem. The README does not describe a recovery or export procedure in the copy available here, and for a cold storage device that is the first document to read before committing funds.

The third is that the security claims are partly unverifiable by the reader. The reproducible build claim is checkable, and the entropy reasoning is laid out in code, but the audit reports are described as pending release, and there is no independent statement in the README about how the secure enclave behaves across the Android and iOS implementations it supports.

The alternative worth comparing is a hardware wallet with a vendor-controlled secure element and a published, if narrower, audit history. The difference in approach is where the trust sits. AirGap Vault puts the trust in a phone you configure yourself, with a key that never touches a network, and it accepts that the phone is a general purpose device rather than a dedicated one. A hardware wallet puts the trust in a purpose-built device with a small attack surface and a vendor with an incentive to keep the audit trail current, and it costs money. For an amount you would be nervous about leaving in a hot wallet, the hardware device is the more conservative choice, and for an amount you are willing to lose, a phone that never connects to anything is a reasonable middle.

Editorial conclusion

AirGap Vault fits a holder of crypto who wants the private key on a device that has never touched a network, and who is prepared to run two apps and move data between them by QR code, because the security property is physical separation rather than a clever algorithm. It is the wrong choice for someone who wants a wallet on the phone they already carry, for a user who cannot accept that the signing device needs its own screen and its own charging cable, and for anyone who needs transaction history in one place, since the split deliberately keeps the two sides from sharing state. Before adopting it, read the entropy seeding code rather than the marketing, confirm your device has a secure enclave and biometric hardware, and check that the release you install is the reproducible build the project claims, since that claim is the part you can verify yourself.

Frequently asked questions

Official sources

1. airgap-it/airgap-vault on GitHub
2. Issues
3. License: MIT
4. README
5. Releases