Announcement: UR Definitions for Transactions Between Airgapped Devices

[wolfmcnally]

Blockchain Commons has just released the first draft of UR Type Definitions for Transactions Between Airgapped Devices. This is an extensible protocol for communication between online and offline devices using URs.

We have currently specified requests and responses for seeds, HDKey derivations, and PSBT signatures.

We look forward to hearing your feedback, and working with you to improve and extend this specification!

[AndreasGassmann]

Hi,

I'm still getting familiar with all the research that is going on here, but I do have one question regarding the "description" field. What is the exact purpose of this field, and have you considered that this might be a potential security issue?

In AirGap Vault, the offline signer in our project, we consider every companion app that communicates with us as compromised. This means that we only display information that we are able to extract from the payload (eg. from the bitcoin transaction itself). We decided against allowing companion apps to provide additional metadata (or descriptions) with requests so users can't be "tricked" into doing something they shouldn't.

I think this issue is more relevant for currencies besides bitcoin, because there, the attack vector is usually bigger. For example, imagine a contract call where someone wants to swap ETH to TokenX. The swap contract (eg. Uniswap) is supported in the offline signer, so instead of a random contract address, it should display name + logo. The malicious companion app can now replace the contract address with a new one and add a description saying "This call is using our new and upgraded contract and your wallet might not correctly display it. If this happens, please contact your wallet to update it". This might give the user a false sense of security and lead to loss of funds.

With bitcoin, I'm sure there are also cases where this could be an issue. For example, the companion app could try to trick the user into believing that one of the outputs is his change address, or that some warning that is displayed in the signer isn't actually that bad, because of any made up reason.

I could even see an attacker create a completely invalid transaction, then add something like "if this transaction fails to sign, please contact our support at ", where they will ask users for their private keys.

This is obviously a worst case scenario, and offline devices can make this harder by using a clear UI (eg. making clear that the description is untrusted). But it still adds a potential attack vector.

[wolfmcnally]

but I do have one question regarding the "description" field. What is the exact purpose of this field, and have you considered that this might be a potential security issue?

It is to be displayed on the responder's screen and clearly labeled as coming from the requester and not actually part of the request that is to be responded to. It's primary purpose is so the requester can explain why they want the response. It should not duplicate or alter information in the request. We're not supporting displaying this information in Gordian Guardian at the moment, and we're open to a community discussion of whether we should have this channel at all. Thoughts, @ChristopherA ?

[ChristopherA]

Yes, there are some legitimate concerns that notes/descriptions/other metadata could be a vector for social engineering attacks.

Yet there are two problems they address:

First is that increasingly Bitcoin is moving to offline functionality. A critical signature for a multisig will not be released without a 2FA (Green Address, Unchained, Casa) or some type of oracle for price or budgetary information Transactions in Watchtowers and Bryan's Covenant mechanisms will be pre-signed but not sent. Timelocked transactions need to be held. It will be even more true with Taproot Schnorr where more offline script effort happens and all the chain sees is the final aggregated signature. You want notes on pub keys to know who holds them, or where you put your offline private key, or who to call.

Secondly, not everything can be expressed inside bitcoin transaction as to "WHY" you should sign or "WHAT" your human role is. Are you an corroborator or an emergency signer? The script and keys are the same, but the first you ask "are these values reasonably" but the second your job is to ask "Why can't the CEO and CFO sign this?". Bitcoin scripts can't know who has already signed, or what the budgets are.

Long-term I think the solutions to prevent social engineering attacks are more specs for domain specific languages that constrain what the metadata can say. But in the meantime, it is the human the has to make the decision. But I do agree we do need to be careful in our UX.

A final consideration, most of the social engineering attacks using this metadata require an internal compromise first. You are unlikely going to be sent a PSBT from someone you don't know, and if it is totally empty of valid signatures, or doesn't come from a trusted source, your wallet shouldn't sign it or warn you strenuously anyhow. In Gordian Cosigner our goal is to use state from past metadata, past transactions, etc. to identify when something looks suspicious or someone is trying to spoof you.

-- Chrisotpher Allen