Bitcoin Forum
December 15, 2024, 12:24:46 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Could the Intel vulnerability have compromised private keys?  (Read 512 times)
codewench
Member
**
Offline Offline

Activity: 93
Merit: 39


View Profile
January 22, 2018, 07:26:14 AM
 #21

what makes you think that such vulnerabilities don't exist in hardware wallets? considering the entire thinking around the security architecture of modern processors and speculative execution was wrong, it stands to reason that this is possible for hardware wallet architecture as well.

Hardware wallets don't execute arbitrary code. They have a defined communication interface that doesn't allow other actions.

The software running on the hardware wallet is also simple enough that one individual can know everything that is happening in the wallet. They can thus verify that there is nothing malicious in the code.

The concern with hardware wallets is if someone gains physical access to your device. The chip(s) may have undocumented ways to gain access. Perhaps if 12 volts is applied to a certain pin, then program code can be injected or observed via other pins. Such a feature may used during manufacture - perhaps for initial wafer level testing. (Decades ago I was able to dump the mask programmed ROM of an embedded microcontroller using just such a feature. This happened to be hinted at in the chip's data sheet.)
ProfWigSlipper
Jr. Member
*
Offline Offline

Activity: 63
Merit: 2


View Profile
January 22, 2018, 02:09:40 PM
 #22

what makes you think that such vulnerabilities don't exist in hardware wallets? considering the entire thinking around the security architecture of modern processors and speculative execution was wrong, it stands to reason that this is possible for hardware wallet architecture as well.

Hardware wallets don't execute arbitrary code. They have a defined communication interface that doesn't allow other actions.

The software running on the hardware wallet is also simple enough that one individual can know everything that is happening in the wallet. They can thus verify that there is nothing malicious in the code.

The concern with hardware wallets is if someone gains physical access to your device. The chip(s) may have undocumented ways to gain access. Perhaps if 12 volts is applied to a certain pin, then program code can be injected or observed via other pins. Such a feature may used during manufacture - perhaps for initial wafer level testing. (Decades ago I was able to dump the mask programmed ROM of an embedded microcontroller using just such a feature. This happened to be hinted at in the chip's data sheet.)

I am light years away from being a qualified expert, but this topic is worthy of continued discussion, imo.
cellard (OP)
Legendary
*
Offline Offline

Activity: 1372
Merit: 1252


View Profile
January 22, 2018, 02:45:05 PM
 #23

what makes you think that such vulnerabilities don't exist in hardware wallets? considering the entire thinking around the security architecture of modern processors and speculative execution was wrong, it stands to reason that this is possible for hardware wallet architecture as well.

Hardware wallets don't execute arbitrary code. They have a defined communication interface that doesn't allow other actions.

The software running on the hardware wallet is also simple enough that one individual can know everything that is happening in the wallet. They can thus verify that there is nothing malicious in the code.

The concern with hardware wallets is if someone gains physical access to your device. The chip(s) may have undocumented ways to gain access. Perhaps if 12 volts is applied to a certain pin, then program code can be injected or observed via other pins. Such a feature may used during manufacture - perhaps for initial wafer level testing. (Decades ago I was able to dump the mask programmed ROM of an embedded microcontroller using just such a feature. This happened to be hinted at in the chip's data sheet.)

You have to trust their propietary RNG and you have to trust they will not have any leaks or try to phone home as we have seen already with Trezor

Generally I can't trust hardware wallets. Linux airgaped computer is the best, because you are never online, but the problem is crafting the raw transaction because the Core client has no other way to do it, I still have to practice that with testnet coins before I consider myself safe to do it with real money.
Hamphser
Sr. Member
****
Offline Offline

Activity: 2604
Merit: 339


Vave.com - Crypto Casino


View Profile
January 22, 2018, 10:30:21 PM
 #24

[...]

Even if I moved all of my private keys into an airgapped laptop which has never seen the internet after being formatted, when I wanted to sign an offline transaction into the online node... the node is still connected to the internet, could somehow a exploit happen in the process?

Signing an offline transaction with an airgapped device won't compromise your private keys, since the online device that transmits the transaction has no access to the private keys on the airgapped device.

However, the following possible exploits still prevail, regardless of Meltdown and Spectre:

-) A compromised USB stick could still grab your private keys from the airgapped device while copying the signed transaction for later transmission using the online device.

-) Simply moving a private key from an online device to an airgapped device will do little for your security. The private keys should be generated by the airgapped device itself.

-) Make sure your device is indeed airgapped and doesn't try to connect to any open Wifis that may be around.


Basically, every offline approach to wallet security still holds. Hot wallets are more susceptible to attacks than ever, at least until the security updates are out.
No matter which way you would go the risk is there since you are importing came from a device thats already connected online. I cant think off that you would able to generate keys offline or on airgapped device.Its little bit worrying about these infomation that even hardwares do already have the possibilities to transmit any other sensible data specially its connection on wallet informations or any other important data.

manchester93
Sr. Member
****
Offline Offline

Activity: 251
Merit: 257



View Profile
January 23, 2018, 12:12:50 AM
Merited by ABCbits (1), marky89 (1)
 #25

what makes you think that such vulnerabilities don't exist in hardware wallets? considering the entire thinking around the security architecture of modern processors and speculative execution was wrong, it stands to reason that this is possible for hardware wallet architecture as well.

Hardware wallets don't execute arbitrary code. They have a defined communication interface that doesn't allow other actions.

The software running on the hardware wallet is also simple enough that one individual can know everything that is happening in the wallet. They can thus verify that there is nothing malicious in the code.

The Meltdown attack was possible because everyone fundamentally misunderstood how authorization worked for memory processes. The same can indeed happen to hardware wallets. Not the Meltdown attack specifically, mind you, but heretofore unknown exploits can and likely do exist for hardware wallets. Anyone who assumes otherwise is incredibly naive.

You have to trust their propietary RNG and you have to trust they will not have any leaks or try to phone home as we have seen already with Trezor

Generally I can't trust hardware wallets. Linux airgaped computer is the best, because you are never online, but the problem is crafting the raw transaction because the Core client has no other way to do it, I still have to practice that with testnet coins before I consider myself safe to do it with real money.

Same here. I wish that Core wallets were capable of signing transactions in an air-gapped (un-synced) environment. The next best thing is Electrum, which has various weaknesses.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!