2

I have made an open source airgapped device for signing bundles offline.

A main purpose is to address the possiblity that the components we use to make our devices are already compromised before they are purchased and yet we still need to use these devices to work with seeds.

So let's imagine I sign a bundle on an infected machine which may have changed the amount of the transactions and also the recipient's address to that of an attacker.

To check for this I would like to broadcast the bundle to the TestNet first to see how much the transactions are and where they are sent.

I understand that sending multiple transactions from the same address gives away information that makes it easier to brute force the seed.

I have two questions:
1. Is the idea basically sound?
2. Does broadcasting a bundle on both MainNet and TestNet facilitate brute forcing the seed?

Thanks for your help.

John Shearing
  • 205
  • 1
  • 8

1 Answers1

2

Your seed is never compromised by address reuse. The only thing that is compromised is the private key of one of your addresses. That's why the wallet moves remaining funds to a different/new address when sending from an address.

Sending the same bundle multiple times (over testnet and mainnet or when reattaching) does not compromise the address. It is only compromised when you send different bundles (with different bundle hash).

So in case you sent a bundle via the testnet, and then realize it was the wrong bundle, you are basically screwed (or at least have to be lucky), as when you send a corrected bundle, it is the second bundle you sent and anybody who is faster than you might steal your IOTA. As soon as your second bundle is confirmed, you are safe again as the key only protects an address that is already empty.

A safer way would probably be to not broadcast the packets (to devnet or mainnet), but look at the trytes in an editor (the recipient address and the amount are at fixed offsets that are always the same) and validate it with your eyes there. The bundle (or the key) may still be invalid and validating that on paper is too hard, but at least you can validate the amount and the addresses easily.

That being said, don't sign bundles on infected (or untrusted) machines. The malware could do more evil stuff than change the address or amount. It could for example encode parts of the (clear text) seed inside the timestamps or the message fields of the transaction. On the other hand, perhaps that is too paranoid.

mihi
  • 7,324
  • 2
  • 15
  • 34
  • Thank you mihi for the clarification,
    It is the address, not the seed which is weakened by multiple spends from the same address.

    If I understand you correctly, using the TestNet to check that a bundle has not been compromised is not a sound idea because an attacker could scoop up the bundle from the TestNet and then broadcast it to the MainNet. I suppose an attacker could even station a bot to listen on the TestNet for infected bundles and then post them right away on the MainNet. Did I understand your point correctly?

     – John Shearing Mar 10 '19 at 19:52
  • A safer way would probably be to not broadcast the packets (to devnet or mainnet), but look at the trytes in an editor

    Forgive me, I am a bit new to IOTA. If I understand correctly, I can look at the bundle signature, pick out the trytes for the amount and the recipient's address at specific locations and then convert them back into a human readable amount and address. Did I get that right? Makes me think it would be a good idea to make a tool to decode the entire signature to verify it will work as expected before sending. Is that a sound idea?

     – John Shearing Mar 10 '19 at 20:01
  • As an alternative, I wonder if it would be a good idea to install an isolated local copy of Compass instead of using the TestNet to check the signature. Does it make any sense to do that or would it be better to make a tool to decode the signature for examination prior to broadcasting to the MainNet? – John Shearing Mar 10 '19 at 20:10
  • ...don't sign bundles on infected (or untrusted) machines.
    Yes but one can never know if the parts to make a machine have not been infected in the supply chain. Our supply chains are centralized and a point of weakness for a decentralized system such as IOTA. If amounts must be sent and back doors can not be ruled out then we are forced to use machines that we do not trust to handle our secrets. How can we do that effectively? This is the general question I am studying. Thanks for all your help     – John Shearing Mar 10 '19 at 21:21
  • When you make a tool to verify transactions, how can you make sure the tool is not compromised by a backdoor? :) When you use Compass, how do you validate the bundle once it is sent there? Checking manually is the best way to avoid backdoors I believe, but of course your text editor could also be backdoored :D – mihi Mar 11 '19 at 21:20
  • Thank you mihi, I am going to try visual inspection of trytes for address and amount before doing anything else. Then I am going to do all the exercises in the MobileFish playlist. Then finally make a tool to check that malware is not putting my seed in the timestamps and such as you had mentioned only if it seems like a solid idea after gaining a better understanding of IOTA. Likely as you have indicated, as I come to know more the idea will not seem so reasonable. Thanks for all the help and advice. – John Shearing Mar 12 '19 at 03:52