Debunking the ‘IOTA Vulnerability Report’
For many months now we constantly see the same report showing up in FUD articles about IOTA. The report is continuously being used to show that IOTA is vulnerable to theft because the signing process uses the Curl hash function, which is supposedly unsafe.
Well guess what? IOTA’s signing process does not use Curl and hasn’t used it since August 2017, which was right before this (arguably malicious hidden agenda based) report came out. A lot of resources have been spent in the mean time trying to debunk this report. Such is the nature of the Internet.
When the writers of the report contacted the IOTA team about the vulnerability it was decided to take no risks and simply replace the Curl function with one that has an identical interface, but its internals instead use the well-known and proven Keccak version of SHA-3. So to reiterate:
IOTA’s signing process is not vulnerable because it no longer uses Curl!
In the mean time, development of Curl is still going on, under the supervision of cryptographical experts. At some point it will have been properly vetted and then it will probably replace the Keccak SHA-3 version again. The whole idea was to be able to use a trinary hash function instead of a binary one, since IOTA was designed to work really well with trinary hardware.
So why is this still a ‘thing’ then?
Well I would say, the whole idea of FUD articles is to destabilize a perceived competitor. Again, the Internet being what it is, it is hardly used to create win-win situations and cooperation between people. It is much easier to just throw some lies or half-truths around to cast doubt on people. It’s also a huge battlefield for ego-driven behavior, in which it becomes more important to be ‘right’ and score points at the cost of the other egos than to have a constructive discussion or -god forbid- come to a common consensus.
So even though there is no collision vulnerability any more the FUD- and ego-battles still rage on. the focus has shifted to some debatable points in the report with people throwing arguments left and right, often trying to score points on a single wording or point of the report, without taking the entirety of the report nor the entirety of the IOTA system into account.
In fact, the report itself conveniently disregards a number of aspects of the IOTA protocol that would make the so-called attacks they came up with bloody unlikely to say the least. The whole purpose of me writing this article is to shed more light on the circumstances necessary for these attacks to succeed. Plus I cannot resist a good puzzle anyway.
I will try to stick to the facts and also try refrain from my opinion on this whole thing shining through too much. But I will say this on record: reading the report (which I did many times) I see a lot of petty behavior, irresponsible behavior, and twisting/omitting assumptions to support the outcome. This could easily have been a sound report if they had kept themselves to the facts and would have refrained from using the sensationalist headline for one. But enough about that. Let’s dive in.
Dissecting the attack vector
Since most of the discussion at the moment is around the point of Eve tricking Alice into signing a bundle that Eve created we will look at the circumstances necessary for that to happen. The basis of the attack is explained in the report like this:
In our attack a malicious user, Eve, tricks a user Alice by asking Alice to sign a message msg1 and then later produces a different message, msg2, which also verifies under that signature.
(1). Eve uses our collision attack on Curl to chooses two messages, msg1, msg2 such that:
CURL_Hash(msg1) = CURL_Hash(msg2) and msg1 != msg2(2). Eve sends msg1 to Alice and asks Alice to sign it.
(3). Alice sends Eve a signature on msg1:
sig1 = IOTA_Sign(SK,msg1)
(4). Eve produces a valid signature,message pair (sig1,msg2) where msg1 is a message which Alice has not signed.
msg1 != msg2 AND IOTA_Sign(SK, msg1) == IOTA_Sign(SK, msg2)By definition Alice has broken the EU-CMA security of IOTA’s signature scheme.
So in short, an effective attack hinges on the fact that Alice will actually sign a transaction bundle sent to her by a party she doesn’t know if she can trust. And it’s not just any message that Alice signs, the report clearly states that this is a chosen message attack:
We emphasize that to produce a signature on a
msg2, our attacks require Alice to sign an innocent-looking related message,msg1, of our choosing. This is a chosen message attack. We have not developed a known message attack.
Prerequisites for the attack
It’s all very easy to say ‘we’re going to trick Alice into signing a bundle’, but pulling that off means that a number of conditions need to be met.
- Since the msg1 and msg2 bundles have to be pre-generated (known message attack, remember?), the attacker (Eve) needs to know the exact address (X) to use by Alice. Which means Eve needs to know without a doubt that Alice owns the address X and can actually sign it.
The easiest way to do that would be for Eve to ask Alice for a receive address X and pay her for something on that address, or for Eve to ask Alice to pay her for something, so that Eve can figure out the remainder address X. Now the trickery can start and Eve may end up stealing her payment back or steal the contents of the remainder address. But that would mean that Alice can easily identify her assailant after the fact. Not a very desirable position for Eve to be in. And the theft is limited to the address X balance. No other funds of Alice’s wallet can be touched.
Note that other than transacting directly with Alice it can be quite difficult for Eve to figure out what addresses Alice owns. She would have to know for sure about any transaction that Alice did. And it would only provide Eve the knowledge about a single address that Alice used to receive funds.
- Now that Eve knows about Alice’s address X, she can pre-generate the msg1 and msg2 bundles. Msg1 will spend a predetermined amount of funds from X to a predetermined address Y, and would need to send the remainder to an (oops! Alice-owned!) address Z. Msg2 will spend all funds from X to a predetermined address Q that is controlled or accessible by Eve.
Now Eve needs to implement her cunning plan to trick Alice into signing the msg1 bundle. But it looks like first she will have to ask Alice for another one of her addresses (Z) to send the remainder after payment to. This is starting to become a game of ‘let’s see how gullible Alice is’.
So Eve says: “Hi Alice, it’s Eve, I would really like you to sign off on this bundle I prepared for you that spends the funds I know you have in address X, to address Y for -insert very plausible reason here-, but to be able to do that I will need you to provide me with a remainder address Z”.
Yeah, right. That does not sound contrived at all. And Alice will never know who hit her once her funds get stolen…
Alice: “Why can’t I simply use my wallet to send directly to Y?”
Eve: “-insert extremely plausible reason here-. Really! Just trust me! I have the plausiblest reasons (in a Trump voice).”
Alice: “I don’t even know how to do that. What the hell is a bundle?”
Eve: “Oh, it’s very easy, I can walk you right through the steps to write a little Java program or use some command line tool. I will just send you an obscure tryte string that could be anything, and then you can send it off. All you need to know is your seed, and the index of address X, so that you can generate the corresponding private keys. You do know that index, right?”
I know, I know, this sounds pretty silly. But maybe that’s because it IS silly. Who in their right mind would ever do something like that? Oh, sorry, I did not know that Alice knows everything about bundles and signing and wants to show off that knowledge. Let’s try again…
Alice: “Why can’t I simply use my wallet to send directly to Y?”
Eve: “Because I know you really know this shit and want to show off?”
Alice: “Oh okay, I can live with that answer. Just send me the bundle trytes that with all my knowledge about IOTA and the scams that people pull I won’t inspect first to see what it does…”
… insert pause while Alice inspects bundle…
Alice: “Okay, looks like you did your homework, but one question: what’s the weird value in the tag field for? Almost looks like a nonce value like the ones used to influence the bundle hash to avoid the number 13 in the normalized bundle trytes…”
I just read the above two conversations out loud to my computer-illiterate wife and she laughed uncontrollably. She asked why anyone would be so stupid. I had to explain to her some of the things I had seen crypto investors do, and even then she did not believe me that people would be stupid enough to fall for this or not realize afterwards that it was Eve that stole their funds.
Anyway, now that we established that Alice must be a crypto investor, and probably generated her seed online, we now continue. Alice is completely fooled by Eve’s cunning plan and willingly signs the bundle by providing her seed, the index of the address, which she happened to have handy, and uses the steps Eve handily provided her with flawlessly:
- Use seed plus index to generate the private key for the address
- Generate a signature for the bundle (which, as luck has it, does not need to be normalized any further, nor contains any 13 values that would need bundle hash regeneration)
- Fill in the signature in the correct fields of the transactions in the bundle
- Request 2 tips to approve from the node and put them in the correct fields
- Do the Proof of Work on every transaction in the bundle or have a node do it for her
- Send the resulting trytes to the node for inclusion in the Tangle
That was easy, right? Anyone can do it! Let’s see how Eve is faring with the next step of her brilliant mastermind plan:
- Now that the msg1 bundle is out there on the Tangle, Eve can look for the msg1 bundle by searching for the address X or the msg1 bundle hash, grab the bundle, extract the signature for address X, insert it into her msg2 bundle, request 2 tips and insert them in the bundle, do PoW on the bundle transactions, and send out the resulting trytes.
Well poop! Now, for the attack to succeed Eve needs to turn it into a race between the two bundles. Alice’s msg1 bundle was posted to the Tangle first, and has more than a PoW cycle head start on Eve’s msg2 bundle. Everything else being equal, msg1 therefore has a higher chance of being confirmed than than msg2. So unless Eve simply wants to play chances she will need to put a lot more effort into getting the msg2 bundle confirmed first. She will need to promote the shit out of it and/or reattach when appropriate. And that still does not guarantee that she will win the race.
And even if Eve would succeed, she cannot use this attack a second time against Alice, unless Alice is really, really stupid (and I mean Bitconnect level stupid) and does not realize it was Eve that stole her funds after all that.
Also, word about this attack would get out quickly, and people would start warning to never sign a bundle that is provided by someone else, just like you never give anyone else your seed. Which of course means it would happen again. There are still lots of Bitconnect investors out there :-P
— THE END —
