5

For me, one of the main use cases for IOTA regarding IOT was to be able to send data and funds in an atomic, immutable way.

E.g. sending a bundle including parameters, transferred in the signatureMessageFragment, and the required funds to a service provider in order to invoke the respective action. Therefore a bundle containing some value and 0-value (for the data payload) transactions is composed. As asked in a previous question, the data transferred in the signatureMessageFragment is not part of the bundle-hash and therefore not signed by the funds transferring tx. A malicious attacker could replay the bundle using different data in the signatureMessageFragment. If his replayed bundle would be confirmed, the service would only see the modified command.

So, how can one send data and funds without anyone being able to change the data. Since the obsoleteTag is part of the bundle-hash, I can only think of the putting all data in the tags, which would lead to many transactions in a bundle, even for little payload. Is there another method? Am I missing something? Wich also poses the question, why the signatureMessageFragment isn't part of the bundle-hash in the case a tx is not transferring funds?

UPDATED according to replies

Task

Invoke a service by sending funds and data in an IOTA bundle.

Procedure

Create a bundle including multiple input tx an output tx and multiple tx carrying data in their signatureMessageFragment.

Issue

SingnatureMessageFragment is not part of the bundle-hash and can thus be changed by an attacker until the bundle is confirmed.

Solution approach

Storing a hash of the signatureMessageFragment in an area which is part of the bundle-hash, such as the obsolete tag. This enables the receiver to verify if the signatureMessageFragment has been changed.

Problem

If the signatureMessageFragment has been modified, the receiver can’t execute the respective action. The funds have already been spent though. The initial data can’t be restored easily. The tangle has to be searched for the original transaction. If a snapshot occurred between sending the initial bundle and the confirmation of the modified bundle, data would only be available by querying a perma-node.

After all, data in a mutable part of a value bundle can always be modified. This this approach doesn’t seem viable to me. In a worst case scenario the data could never be transferred.

Improve this question
4
  • I assume you had a look at MAM already and it did not fulfill this requirement? (to be honest I did not have a look at how MAM is exactly implemented, but I thought it should solve this use case).
    – mihi ♦
    Commented Jan 13, 2018 at 14:27
  • How about putting checksum of the message into obsoleteTag?
    – alexpods
    Commented Jan 13, 2018 at 16:39
  • @alexpods this way the receiver could identify a modified transaction, but the initial data can’t be restored easily. He would have to search the tangle for the original transaction and extract the data from this one. Not sure what could be wrong by doing so. What happens if a snapshot occurred meanwhile and the initial tx is only available on a permanode.
    – Akkumulator
    Commented Jan 13, 2018 at 16:44
  • @mihi the problem arises based on the fact that I want to send data and funds in one bundle. Sending only data should be no problem since those tx cant be replaced. (they don't carry funds and thus can't be conflicting)
    – Akkumulator
    Commented Jan 15, 2018 at 9:06

1 Answer 1

Reset to default
5

The current transaction structure is not the final variant. Later extraDataDigest field will be added, that field will be a part of the bundle essence (signed part). Setting the field value to the hash of signatureMessageFragment would allow to detect cases of changed content.

You could use obsoleteTag now (store the hash fragment into the last 27-N trytes, because the first N trytes can be changed during the signing).

signatureMessageFragment is not a part of the bundle essence in cases when the transaction is not transferring iotas because doing otherwise would make bundle validation more resource-consuming which is bad for the IoT.

Improve this answer
8
  • Thanks for the clarification. One issue which still remains is that anyone could change the signatureMessageFragment. I would be able to detect the change, but the funds sent in this bundle would be kind of lost. A complicated mechanism for checking if the data was changed and somehow resending the correct data to the already transferred funds would be needed. Also, what would be a use case (for an iot device) for data transfer, where sender verification (by signing) is not required?
    – Akkumulator
    Commented Jan 13, 2018 at 14:16
  • A sender can be verified by spending N iotas from an address (even with 0 balance) and sending them back to the very same address.
    – Come-from-Beyond
    Commented Jan 13, 2018 at 15:57
  • Don't you want to do that only with a zero-balance address? Otherwise part of your private key will be exposed while you still have funds in that address?
    – BugFreeSoftware
    Commented Jan 28, 2018 at 18:40
  • Right, preferably with a zero-balance address, though special procedures allow to spend more than once without much risk.
    – Come-from-Beyond
    Commented Jan 28, 2018 at 19:14
  • Could you please elaborate on those special procedures?
    – BugFreeSoftware
    Commented Feb 1, 2018 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.