An attack with fake outputs from malicious node

[lunfardo314]

An attack with fake outputs

Assumptions

• New Stardust output types introduce metadata in outputs. It is not interpreted by the protocol, so L1 accepts any of it
• The node API provides to clients only outputs and their IDs, in pairs.
• Transactions are not stored on the node, they are pruned, therefore not available to the client.
• There's no way for the client to check if the data provided with output ID is genuine.

The attack

Malicious public node which wallet is connected to, can easily fake the output data, while keeping genuine output IDs. Wallet has no means to check validity of it.

Specifically, mutable metadata block is not validated by the protocol, therefore it can be replaced by arbitrary data.

This feature makes it possible for the malicious node attack the L2 apps which interpret metadata field in it own way.

Examples

Naughty Eve

Alice is running an app:

• the app permanently reads her donations address and collects the iotas sent to her by consuming UTXOs and consolidating iotas in her another address
• If the UTXO with output also contains metadata block, the app interprets the message by posting it as a string to Alice's public website together with the donated amount.
• Eve runs a public node. She modifies the node's API the following simple way: in all requested by API outputs in metadata block she replaces all occurrences of string love to hate.
• Bob donates 1000i to Alice by sending UTXO with metadata field I love you.
• Eve provides the UTXO with faked metadata block to Alice
• Alice consumes faked UTXO, collects the donation and displays message 1000i from Bob: I hate you.
• this way any love expressed to Alice will be converted into hate without good way to detect it, because consumed UTXOs will soon be pruned

Potential stealing of funds

If L2 wallet interprets the metadata block as a command to send funds or sender block as owner of funds, the funds can easily be stolen with this attack. This is exactly the case Stardust VM, especially if smart contract chain is run with one validator.

Proposed solution at the protocol level

In the protocol, we could require hash of all concatenated data of inputs used to produce the transaction by the wallet as a part of the transaction essence (signed).

This way the transaction will contain not only output IDs of outputs, but also commitment to the data of outputs used to produce the transaction.

The validation of transaction should be extended with checking in the validation context if hash of referenced outputs by inputs is equal to the hash included into the essence. If wallet used faked inputs, the transaction will be invalidated.

Pros

• it prevents the attack. Malicious node will not be able to make the wallet to produce a formally valid transaction with otherwise wrong outcome in the ledger
• solution is a simple extension of the protocol in iota.go
• storage overhead is only 32 bytes per one transaction
• we can keep sending only outputs from API (alternatively we would need to keep and send entire transactions)

Cons

• some, rather small, processor overhead in transaction validation
• the client still won't be able to detect faked output data. The produced transaction will look valid to the wallet (however it won't be confirmed)

[lzpap]

This problem is present and known in many other UTXO based DLTs, such as Bitcoin for example.

One example is this attack. Bitcoin (partly) mitigates these type of attacks with SegWit transactions as per BIP-0143. It describes a commitment to the bitcoin amounts in inputs in the signature generated by the client. If the outputs used as inputs actually have different amounts, the signature of the client is invalid.

The solution @lunfardo314 describes is a more generalized version of this approach, where the commitment is actually made to the raw output content.

What are the implications of putting the commitment to the content of inputs:

• In the signature generation algorithm,
• in the hash of the transaction essence to be signed (i.e. transaction essence contains commitment to serialized inputs),
• or as an explicit field in the transaction as described above?

[lzpap]

if it is a known issue it is a serious flaw we have to avoid, not leave unsolved.

In bitcoin and other networks, the solution is to run your own node, trust nobody.

Your assumption above is that you can't run/access trusted nodes as a client. Then the commitment to the inputs is the only solution afaik.

[lunfardo314]

the solution is to run your own node, trust nobody.

in general, this is a very strong and limiting assumption

[jorgemmsilva]

in the hash of the transaction essence to be signed (i.e. transaction essence contains commitment to serialized inputs),

I like this approach, is there any downside of doing it this way?

[jorgemmsilva]

actually, considering #56 , if we follow a similar approach, we will be pushing many things to the signature:

<tx essense> + <inputs hash> + <network ID>

which is fine IMO, but we might want to be careful to try to keep the signature/verification process simple

[lunfardo314]

Including hash into essence and signing inputs without including the hash both solves the problem but they are not 100% equivalent approaches. If you only sign the the inputs, you will never know why the tx is invalid: what if you used wrong private key? Having the hash allows the protocol immediately detect that inputs were faked and you could track it to the malicious node (usually)

[luca-moser]

The problem you have outlined is completely correct, there is currently no commitment by the client about the data of the inputs of their transaction, hence a node supplying altered output data can have severe effects if the application is reliant on the information within the outputs. Adding the commitment as outlined would in the worst case only result in an invalid transaction. As @jorgemmsilva mentioned, appending the hash to the signing function instead of adding it to the tx should work, I believe the only thing we would lose is the ability to say straight away: "the inputs don't match" (as a step before signature verification).

Would the addition of having to hash the inputs have any impact on hardware based signers?

Having said that, I do not believe that adding this lifts the requirement of having clients to trust the nodes they connect to. By trust I mean not only retrieving untampered data but also valid responses of any kind for queries the client runs against the node: i.e. nodes responding with data being absent (even if it actually exists) or not pushing data (in event based clients). Also assurance of having the client's transaction disseminated requires trust for the node to do the right thing. Arguable these aren't very critical but you still would not connect to any random node to interact with the network because of them.

It also is an open question whether producing invalid transactions is something a client is ok with. In most cases I presume clients do not even want to run into the risks of producing them, hence they use a trusted node in the first place.

[samuel-rufi]

Fully agree, it doesn't fix the trust problem with using public third party nodes completely. As you said, there are still other ways for nodes to cheat - might be however not as critical as this "fake output attack".
A client however that wants to make use of public nodes should in any case fetch a quorum of nodes instead to mitigate the attacks.

[laumair]

Quorum is supported in the current form of clients implementation, however, not enabled by default (as it adds overhead). Usually, it is assumed that the consumer of the client libraries will use a single (trusted) endpoint.

[lunfardo314]

The node can send you any rubbish it wants. You can never trust any individual node, even if it is yours, because there are layers (OS, network) which rarely be yours anyway. We still want to trust the protocol without trusting any individual part of the system. The whole point of the system being distributed is to remove trust assumptions as much as possible, hence “trustless”. Talking about nodes, you will ask the same question multiple nodes and compare answers: more nodes you ask, more “trustless” it will become.
In this case, the fake outputs attack is possible exactly because we assume we trust the node and this assumption is a part of the protocol. So we have to remove trust assumptions from the protocol as much as possible, this is our goal as designers. Then you won’t need to trust the node to trust the protocol

[hmoog]

I want to chime into this discussion and we are facing a very similar problem in goshimmer.

For local snapshots and to detect the possible corruptions of the snapshost files by malicious actors, we are going to create cryptographic commitments in the messages that commit to the root of a merkle tree over all unspent outputs from some epochs ago (we commit to the OutputID of the existing Output).

Currently, the OutputID does however only depend on the TransactionID and its index, which doesn't allow us to do any verification of the content of that Output (in regards to its OutputID).

What we would essentially need is a way for the OutputID to commit not just to its "origin" (TransactionID + Index) but also to its "content/metadata".

I therefore propose the following change to the way we calculate the OutputID:

OutputStateCommitment = Hash(DataInOutput)

OutputID = Hash(TransactionID + OutputIndex + StateCommitment)

This now gives us the ability to associate the OutputID with its actual content which will not just enable validate-able local snapshots for goshimmer, but it will also prevent the attack discussed above without putting any extra effort on hardware signers for transactions (as the OutputID is provided by the node).

I think this solution is much more powerful and efficient, than to put extra commitments into each Transaction that the user needs to sign.

[alexsporn]

I like the idea. Do not see any downsides directly. We would then need to change the format of the UTXO Inputs in the TransactionEssence

[samuel-rufi]

+1

[Thoralf-M]

One possible downside would be, that you don't know the transaction id with the output id alone, you would first need to request the output metadata

But I guess it's not really a problem anywhere

[lunfardo314]

this would make output ID a completely random value. That could have serious practical implications in the code, such as inability to reference the transaction and output's siblings by the data of the output ID without going to some index on the node (which, among other things, again introduces trust assumptions) or by having the whole transaction. That will definitely have implication in the VM and the protocol with L1.
So, this approach solves this very problem as well, however I have a feeling it has more downsides than advantages in general.