Currently, we use our own Serializer to encode the data we transfer in an efficient way. It also supports “splitting up” QR codes into multiple chunks, which allows us to transfer transactions with many inputs or outputs that don’t fit into a single QR code.
On our support page, we have a small page that shows a few examples and contains instructions on how the content of the QR codes can be inspected using 3rd party tools.
https://support.airgap.it/coinlib/examples/serializer/v2/introductionA small note here: We’re working on a bigger refactoring of our apps to support Segwit and PSBTs. Once this is done, there will be an option to encode the data in different formats, for example, bc-ur, to be compatible with other watch-only wallets like Electrum or Sparrow.
So that’s just some background information, let’s get to your questions:
How the tx's is being transferred from the Vault to the Wallet? (QR Code) without the source being contaminated or altered using Malware?
We generally assume that the offline device (Vault) can be trusted. If you don’t trust the offline device, you will have to inspect every QR code going from Vault => Wallet yourself (using 3rd party tools) to make sure no sensitive data is leaked. Sadly, this is not as easy as it sounds. By inspecting the contents of a QR code, you might catch some simple attempts to leak private data (eg. if part of the seed is put into the identifier). But sophisticated attacks, for example abusing the “random number” of an ECDSA signature, can leak data in a way that is practically impossible to detect. (See
https://core.ac.uk/download/pdf/301367593.pdf). Because air-gapped and offline wallets get more and more popular, we have started a discussion about exactly this issue, but sadly there were no responses so far. Feel free to participate to show other developers that this is an issue we should be looking into:
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/60Would it not be more secure if the tx's could be encrypted between the source and destination?
Not necessarily. There are advantages and disadvantages to encrypting the messages that are sent between online and offline devices:
Advantages:
- Privacy (nobody can read the contents of your message)
Disadvantages:
- The messages can no longer be inspected by 3rd party tools (at least not with considerable extra work)
- More complexity overall (an additional key/keypair has to be generated for the communication, and it has to be shared between offline and online device)
While encryption obviously also prevents Man-In-The-Middle attacks (if the right encryption is used), this could also be solved by adding a signature to the data. So the only actual benefit of the encryption is that nobody can read its content.
Because of the additional complexity, the downsides regarding verifiability of the messages and no real security advantages, we decided against implementing encrypted messages for now. The thread of a “Man-In-The-Middle” attack is also relatively low in our case, because the communication happens directly between the 2 devices, it is not sent over the network, for example. But we still have it in our backlog to add as an optional feature for those who want it.
but the Private Key must be encrypted at all times.
While we don’t support your specific use case (we only support BIP39 mnemonics, not private keys), the mnemonics in AirGap Vault are always encrypted, unless they are needed for some action (eg. deriving of the keypair or signing).
Let us know if you have any feedback regarding those points. We’re always happy to have those technical discussions
