before bitcoin having a 0day in windows/Linux meant you could steal information, which wasn't all the profitable as you probably had to find someone willing to buy it.
today having a 0day in windows/Linux means you can anonymously rob a bitcoin exchange/whale and instantly become a millionaire.
sure you could say hackers could always steal banking credentials and steal money that way.
but banks usually call their customers when they attempt to make large wire transfers, no such luck with bitcoin.
Exchanges Whales have the private keys to most of their bitcoins on devices that have never been connected to the internet.
It's more like they can rob a few people that are to ignorant to secure their coins.
even if the device isn't connected to the internet transactions have to go in and out of it to be signed.
if there is a vulnerability in the code that does the signing a hacker could steal the private keys from the signing device.
But that doesn't have anything to do with 0day Windows/Linux vulnerabilities, which is what you asked for. It's rather a problem of the wallet software used on the device, but thats a general problem which is unrelated to Windows/Linux vulnerabilities.
Also, transactions do not necessarily have to go in to be signed. It is possible to feed the device the necessary information about previous outputs without connecting it to the internet. This allows the device to create and sign transactions in one go. They can then be put on an unused USB stick and taken to an Internet connected computer to be broadcast.
if you feed the device any information its possible, some would even say probable, that the code that parses this information has a vulnerability somewhere which would allow an attacker to take control of the signing device and leak the private keys into the USB stick.
obviously exploiting custom embedded systems takes more effort than commonly used windows or linux machines, but it can be done and considering the reward seems even probable.
The probability that any code has a vulnerability is always there. Again thats nothing specific to a Windows/Linux vulnerability or any vulnerability of any code that runs on specific device.
Of course you are right that such a vulnerability could result in a loss of coins but thats a vulnerability of software specifically made for a device specifically made for keeps your coins secure. It's not a general 0 day Windows/Linux vulnerability.
In your example one simply shouldn't connect the USB stick to a device connected to the Internet before deleting the additional information that has been leaked on the USB stick. It's not like you can hide it so there shouldn't be a problem just deleting it. This can add an additional level of security.
Also it isn't necessary to use the USB stick at all. You can just type in the whole Tx Hex while reading it from the device (might take a few tries but it would definitely work). You can always be sure nothing has been leaked by just examining the data you are about to carry over from the device to an online computer before you feed them to the online computer - not the hardest of things to do.
if you have a hardware wallet that makes its own private key away from windows/linux and the internet. a person funds it through the public key,
and all the hardware wallet has is a camera(read QR code for destination) and a numeric keypad (type in amount).
then a hardware wallet will only ever ask for initial balance update (typed in), how much to spend (typed in), destination(scan QR code). and display a signed transaction as a easy to display QR code.(on screen)
it would not need to go to the internet to check balance. it would send the 'change' back to address it owns.
the only information in would be destination and amounts. and the only information coming out is a signed TX
.. oh and the sourcecode never gets updated, so no worries of trojaned firmware updates.
.. now thats how i perceive a true hardware wallet.
What do you mean by "initial balance update"? If you mean you tell the device how much money are on the address (addresses?), then that won't work. In order to create a transaction you do not need to know the balance of an address. The only thing you need to know is the output of the transaction that has send the money to the address because this is what has to be referenced in a transaction in order for it to be valid. So what you'd need to make the device know is what unspent outputs are on the addresses it uses.
Theres an easy way to do this... by just using SPV data which is very small and therefore can be easily fed to the device.
