that was a poorly maintained, quickly built rarely used library and ambitious beyond capability software development that made u vulnerable.
I'm very sorry for your loss. if $12k was all it took, then you've learned a valuable lesson about yourself and I wish you much fortune in whatever you find next
Holeeeshit. I think I gathered lots of these pieces from following people like Levin as they discovered the depth of this vulnerability, but it is really bad to see it all written out in one place. It sure does make Bitcoin sound like a bunch of larpers.
This is a great explanation of the role of randomness in generating a key:
Your Bitcoin secret key rests entirely on a single number, drawn at random once and for all on the day it is created. That 128 or 256 bit number is encoded as 12 or 24 words, then derived into a full tree of keys and addresses. Nothing protects your bitcoins but the statistical impossibility of guessing that number.
On Coldcard's lack of documentation around sees generation:
No written requirement said where seed entropy had to come from, so the implementation had nothing to visibly contradict, and anyone auditing the code had nothing to check it against.
Although I read this second Coldcard post, I misses this line that Kevin points out:
the guard itself, he [the author of the Coldcard security advisories] explains that he set the macro to zero thinking it meant neither implementation would be built, which is not what it does.
I suppose I've used lots of things without really knowing what they do, but god damn, it's kind of like CC had one job here and they didn't even know what the function did?
But perhaps this actually reveals something deeper in Bitcoin: most of the hardware wallet/security industry is about keeping your coins safe, not setting up your seeds.
I have a very clear memory of the first time someone explained to me that you probably shouldn't just trust a seed generated by a device. You don't really have any way of checking how random it actually is. This isn't something that newbies are told.
If you generated your seed on a Coldcard and then imported it elsewhere, onto any other hardware wallet of any brand, you are affected in exactly the same way. It is the seed that is at fault, not the device it lives on today.
Seeds are the foundation. All the precautions in the world won't help you if your seed is bad. We probably need to put a lot more emphasis on this. I've also likes that Kevin and the rest of the guys at Wizardsardine usually refer to Coldcards and BitBoxes and such devices as hardware signer not hardware wallets. The device exists for helping you compute signatures, not for creating seeds.
And then there is all the stuff about how thoroughly CC fucked this up. Wow.
The clone-to-another-device function is broken too. The mechanism relies on an ephemeral key exchange between the two Coldcards, over the SD card, from which the transfer’s encryption key is derived. Since those ephemeral keys come from the faulty generator, anyone who gets hold of the clone file can recompute them, redo the exchange and decrypt everything, and so recover the seed in the clear. Even if that seed was generated with dice.
Any seed created on a Coldcard since 2021 has to be treated as public. And if the seed is public, so is the entire transaction history that flows from it, retroactively and permanently.
Kevin concludes with this good advice:
Just make sure no spending path can be satisfied with the keys of a single brand.
I suppose I've used lots of things without really knowing what they do, but god damn, it's kind of like CC had one job here and they didn't even know what the function did?
C macros are hard to track, especially if you don't review for it. It's a preprocessor statement, so what you put there is processed by a little script before things get passed off to a compiler and a linker, that processes the actual code. One of the things I do when writing things that need a macro other than a simple header guard (or sometimes, complex combinations of these) is to put error macros inside these and their inverse, run a compilation, and then see if it does what I expect. That is something I learned to do, so that I don't propose bugs / bother people with poor code, after fucking up a couple of times and luckily getting called out for being a fucking retard during patch review.
Now, the question I'd ask here is: who was reviewing? Who was the backstop? Did they "LGTM" the patches or did they actually spend time. Review takes more time than coding if you have competent reviewers.
Even if that seed was generated with dice.
This is the main reason why I said read it carefully. There is a list of functions there that are important to note. Most importantly, I think, the XOR key split with random data and the device clone over SD. Any of the former type key should be rolled too, and any SD ever used for device clone should be secure wiped and/or shredded (don't throw it in the trash.)
This vulnerability in the Colcard has been exploited by a group of hackers, as the amount of BTC stolen suggests it's the work of more than one person. So far, there have been two waves of attacks. The first, on July 30th, extracted 1082.65 BTC from 1195 addresses in 41 minutes. The second, which began on the morning of July 31st, extracted 76.16 BTC from 1478 addresses over 3 hours and 42 minutes. Many Bitcoin users who have these wallets stored in cold storage haven't even heard about these attacks. How sad to have trusted one of the best wallets and then lose your BTC due to a vulnerability beyond the user's control! And there's talk of a third attack, we don't know if it's true!! What sad days for Bitcoiners!!!!
Lost about $12k CAD worth.
I think I'm done guys. AI has made the world around us extremely vulnerable.
Sorry for your loss
#1537410
that was a poorly maintained, quickly built rarely used library and ambitious beyond capability software development that made u vulnerable.
I'm very sorry for your loss. if $12k was all it took, then you've learned a valuable lesson about yourself and I wish you much fortune in whatever you find next
Oh no! I'm sorry! This is among the shittiest things that can happen :-/
Holeeeshit. I think I gathered lots of these pieces from following people like Levin as they discovered the depth of this vulnerability, but it is really bad to see it all written out in one place. It sure does make Bitcoin sound like a bunch of larpers.
This is a great explanation of the role of randomness in generating a key:
On Coldcard's lack of documentation around sees generation:
Although I read this second Coldcard post, I misses this line that Kevin points out:
I suppose I've used lots of things without really knowing what they do, but god damn, it's kind of like CC had one job here and they didn't even know what the function did?
But perhaps this actually reveals something deeper in Bitcoin: most of the hardware wallet/security industry is about keeping your coins safe, not setting up your seeds.
I have a very clear memory of the first time someone explained to me that you probably shouldn't just trust a seed generated by a device. You don't really have any way of checking how random it actually is. This isn't something that newbies are told.
Seeds are the foundation. All the precautions in the world won't help you if your seed is bad. We probably need to put a lot more emphasis on this. I've also likes that Kevin and the rest of the guys at Wizardsardine usually refer to Coldcards and BitBoxes and such devices as hardware signer not hardware wallets. The device exists for helping you compute signatures, not for creating seeds.
And then there is all the stuff about how thoroughly CC fucked this up. Wow.
Any seed created on a Coldcard since 2021 has to be treated as public. And if the seed is public, so is the entire transaction history that flows from it, retroactively and permanently.
Kevin concludes with this good advice:
Just make sure no spending path can be satisfied with the keys of a single brand.
C macros are hard to track, especially if you don't review for it. It's a preprocessor statement, so what you put there is processed by a little script before things get passed off to a compiler and a linker, that processes the actual code. One of the things I do when writing things that need a macro other than a simple header guard (or sometimes, complex combinations of these) is to put
errormacros inside these and their inverse, run a compilation, and then see if it does what I expect. That is something I learned to do, so that I don't propose bugs / bother people with poor code, after fucking up a couple of times and luckily getting called out for being a fucking retard during patch review.Now, the question I'd ask here is: who was reviewing? Who was the backstop? Did they "LGTM" the patches or did they actually spend time. Review takes more time than coding if you have competent reviewers.
This is the main reason why I said read it carefully. There is a list of functions there that are important to note. Most importantly, I think, the XOR key split with random data and the device clone over SD. Any of the former type key should be rolled too, and any SD ever used for device clone should be secure wiped and/or shredded (don't throw it in the trash.)
it is what it is...
⏪⏫🐥 ⏬⏩
Very good read, but read it very carefully, all of it, and make sure you understand what is written there exactly (or you may make poor choices.)
This vulnerability in the Colcard has been exploited by a group of hackers, as the amount of BTC stolen suggests it's the work of more than one person. So far, there have been two waves of attacks. The first, on July 30th, extracted 1082.65 BTC from 1195 addresses in 41 minutes. The second, which began on the morning of July 31st, extracted 76.16 BTC from 1478 addresses over 3 hours and 42 minutes. Many Bitcoin users who have these wallets stored in cold storage haven't even heard about these attacks. How sad to have trusted one of the best wallets and then lose your BTC due to a vulnerability beyond the user's control!
And there's talk of a third attack, we don't know if it's true!! What sad days for Bitcoiners!!!!
@DarthCoin always recommended Coldcard.