Hardware wallet for SafeNetwork


#1

I am curious how is SafeNet encryption designed. Imagine you are running infected computer which can use all the hacks and tricks to steal the account with all the data and coins. I myself do not feel comfortable to hold any crypto in computer and I will not feel comfortable to use Safenet either if it would mean I am risking my coins. The more coins I have on my account the less likely I will use it at all. So my question is, how is safenet designed. If there were some hardware wallet manufacturer willing to create hardware wallet for safenet, would it be possible to let all the encryption do on that hardware wallet without requiring to let access to keys to the computer? It would be awesome to have an option to stick such device to USB drive into infected computer and be 100% sure nothing can steal your assets. I am sure such device will sooner or later exist, but my question is, if safenet client is designed that way, that encryption and authentication can be done externally by some external plugin.


#2

I’m a big fan of hardware wallets too.

AFAIK you can just use any existing ‘password’ hardware wallet. So you don’t need specialist kit like trezor or ledger. Your SAFE account is accessed through passwords, so any external hardware wallet that handles passwords can be used to protect your SAFE login credentials.

I think that’s the gist of what I was told when I asked the same question :wink: Seems obvious when you think about it I guess.


#3

@Antifragile, if you do a search on hardware wallet you should find some recent discussions on this.

The difference that SAFE makes is that all your keys are held on the network and used by the SAFE software to sign well almost everything.

If you were to totally remove the key processing from the client app running on your computer then the hardware device would have to have all the software running on it. Essentially one of the SBCs running a “ARM” version of linux that is doing the SAFE code.

Otherwise as @Jabba says a password device is all that should be needed.

Remember that everything on SAFE is using encryption and your keys are never “in the clear” except for when SAFE client is signing something. The keyboard is not needed for this process so anything that might “steal” a key is running in the computer inspecting memory. A hardware wallet for SAFE is not going to help here but rather as I said before you need an actual SBC (Single board computer) built into a USB dongle that runs the SAFE client and does the work for you.

Also any computer thus infected can cause problems for any current hardware wallet also.

I do like the idea of a SBC in a dongle to do all the key stuff for SAFE, it’d be nice to just plug in a dongle to any computer and know its safe.

Mind you another option is to have a bootable version of linux on a USB and boot to that and that way you have a known environment and no need to trust anything on the computer and no pesky malware trying to interfere.


#4

Password manager does not help here. Once password manager gives credentials to Safe client, than all the keys are in computer memory. I am talking about hardware that will never ever send any keys or passwords. Somethink like trezor, that signs transactions,so the keys never leave the device. The pattern is that anytime client needs to encrypt something, it calls hardware wallet api to do the signing/encrypting/decrypting or whatever work that need to work with private keys. Sooner or later there will be viruses specializing on safe coin stealing from infected computer memory. Trusted and prefabricated hardware solution will have to come. So I want to find out, what is the way how to do it.


#5

That is what I want to find out. If the device has to run latest version of safe client, hence become obsolete after new version of client is released, or if client is designed that way, that hardware solution does not need to run the whole client, but it can do all the signing work only. This way such hardaware wallet will have to run only small part of code and will work even if client code has changed a lot. So in general if it is possible to replace internal signing classes with some external solution.


#6

The biggest problem here is that for hardware signing transactions you are talking of there is only a few hundred bytes being signed. For safe the encryption can involve Giga Bytes in a very short time. The mechanics of it makes it a near impossible task for mere hardware style of wallet.

Also SAFE is engineered to not keep your keys in memory. They are actually stored encrypted on the network (anyhow) so having a hardware wallet is an extra place for bugs/lost of keys to occur.

Now for something like protecting your credentials, this is possible and requiring only a small change to the client software where the client receives the encrypted credentials (ie what the client usually does with your entered credentials). To make it secure then they are encrypted with a handshake mechanism from client->hardware->client.

But you have to realise that the keys are stored on the network anyhow. The client is always decrypting the data sent to it from the network and to try and have an additional piece of hardware doubles up where the keys are, introduces large delays as the data is passed through the USB to the hardware which then decodes it and passes it back. The processor in the hardware will be much slower than the PC.

So watching your movie will become difficult with all this data handling slowing things down. Especially since the keys are on the network anyhow.

It is not like the internet where a server having your keys is vulnerable and keyloggers can grab the keys. But rather the SAFE network is holding the keys and if it was cracked then your keys won’t protect you anyhow.

tl;dr

  • The keys are stored on the network anyhow
  • If your keys are discovered on the network then the network has been cracked and everyone’s keys mean swat
  • Keys/signing for the safe network is a whole lot different than crypto hardware wallets. THe keys are used for every interaction with the safe network.
  • Even if you try to restrict it to safecoin transactions the keys are for the ID which is used for a lot more than just safecoin transactions. Its the ID keys not just some address private key like BTC
  • The volume of data for which the keys are used to decrypt is 1000’s or millions times more than for crypto wallets.

#7

If credentials can be kept safely on the external device it should be safe. The credentials could only reside on the external device and the computer will just get an encrypted version of credentials that will be sent on to the network, encrypted together with a nonce, so that if malware on the computer managed to steal the encrypted login information it wouldn’t be useful to login again from another computer, so an attacker couldn’t use it to login from anywhere else.


#8

Its not he network that needs them, the network is already storing them. What about decoding that MD that your computer needs to process? Or the string of MDs that is storing that important data.

Its that the client is using the keys to en/decode a lot of things. And the volume of data to be decoded could be large.

The hardware wallet was designed and good for signing transactions for blockchain transactions and the computer passes that onto the blockchain network. This is a great use case. The hardware wallet is processing very small amounts of information and small (cpu, memory) powered devices that can fit in a hardware wallet can do this easily.

Now for SAFE the keys are used to encode and decode up to a megabyte of data at once. Hardware wallets are not really up to that task. They don’t have enough internal ram for one and not enough processing grunt. SAFE is not using keys like a blockchain wallet is using keys and therein lies the problems for a hardware style wallet.

Now we need an alternative system that can keep your keys safe while they are being used.

Maybe a secure USB device that is read only (with a secure write enable :wink: ) and contains an APP (or actual OS that boots from the USB).

We are still at the point were we need the power of a decent computer with RAM to do the en/decryption of MDs etc.

Now if there was a specific use case for this safe hardware “wallet” like countersigning SAFEcoin transactions then that would be good. It uses your credentials and wallet ID’s keys to send the transaction to the network might be a viable use case for a hardware style wallet


#9

Okay, so let me see if I get this right now.

It seems it’s using the password to fetch a “passport” that contains the private keys, and these private keys are decrypted by the symmetric encryption key derived from the password. If using a hardware device then that device could then store/cache the passport and the “backup” that you write on paper or cryptosteel to recover the keys would then be the secret/username and password?

A hardware wallet would use the private keys found in the passport to encrypt and decrypt data that is being fetched or sent to the network, but the problem with current hardware wallets is that they’re slow and made for signing small transactions, not quickly encrypting or decrypting gigabytes of data? Looked at some hardware wallet specs, the most powerful ones seems to still measure their processing power in megahertz and their memory in megabytes.


#10

Ledger has signed a deal with Intel to start using SGX enclaves in their products. I still need to read about how these work, but maybe an enclave in a PC could provide similar security?
https://software.intel.com/en-us/sgx

Side notes

  • Ledger taking heat for dealing with a company who have backdoored products in the past.
  • Ledger CEO gave talk on enclaves at Devon 3 (I haven’t seen it yet)

#11

I would be very dubious of Intel SGX/AMD SME enclaves as a solution - definitely not as secure as external hardware wallet solution:

Minix intels hidden in chip operating system


#12

See also: https://eprint.iacr.org/2016/086

“After learning about the SGX implementation and
inferring its design constraints, we discarded our draft
proposals for defending enclave software against cache
timing attacks. We concluded that it would be impossi-
ble to claim to provide this kind of guarantee given the
design constraints and all the unknowns surrounding the
SGX implementation…
We hope that it will help fellow researchers understand
the breadth of issues that need to be considered before
accepting a trusted hardware design as secure. We also
hope that our work will prompt the research community
to expect more openness from the vendors who ask us to
trust their hardware.”


#13

@krnelson

Lets face it you are not going to get away from the keys being on the computing device that does the main grunt work. SAFE is all about encoding and decoding and its at every stage of the data flow.

Either you have a device that can do all that grunt work and it fits in a handy little device.

OR you find a special use case for the “hardware wallet” like a (counter) signing of the safecoin sending. But even that involves multiple keys and data passing between client and hardware device. The device would have to be updated with latest client too in order to be able to securely and correctly perform the transaction.

But in all cases it is really a separate computer running SAFE code that you know to be clean. Just run it on a phone or tablet that is not used for other things, just as cheap for a small one and more capable.


#14

The DevCon3 talk by btchip (Ledger)


#15

Since Etherium is still a blockchain and the transactions are such. Then its great for the smart contracts running on the blockchain. Small and just signing the contract.

Doubt though this would be suitable for even performing the safecoin transaction since it will be using the safe client code. A safe coin transaction will essentially be the same transaction as any other MD owner transfer with the wallet APP handling the process. Its the network core code that will handle the safecoin transfer differently because of its tag type and special code for it. On the client side the safe code (client) just handles it as if its any other MD owner change request and the APP provides the user with the coin transfer experience.

So I do wonder from this if any hardware used for “hardware wallets” is even capable of any client code processing, even if its just a MD owner transfer. That amount of RAM is miniscule for the SAFE processing. Better with a cheap tablet/phone that is not internet connected.


#16

For SGX the protected memory space looks pretty large (“typical values are 64 MB and 128 MB”). However, “enclaves cannot perform any I/O operations”, so I think it would be limited in usefulness.


#17

I found an interesting paper about an SGX based library OS. The idea is to make existing applications easily run inside of a secure enclave. The paper outlines performance metrics for running, among other things, Apache web server and CURL inside of an enclave, as well as metrics for file accesses.

“Intel SGX introduces a number of essential hardware features that allow an application to protect itself from the host OS, hypervisor, BIOS, and other software. With SGX, part or all of an application can run in an enclave” To port a complex application to SGX “…the options for the user or developer become: (1) modifying the application to require less of the runtime; (2) opening and shielding more interfaces to the untrusted OS; (3) pulling more functionality into a shim or a library OS. The goal of this paper is to provide an efficient baseline, based on (3), so that users can quickly run applications on SGX, and developers can explore (1) or (2) at their leisure.”

The github page of the project:


#18

Maybe a hardware specific device with safeclient and enough processing power is a ways off. However, we could implement 2nd Factor authentication necessary for authorizing spends (trezor style), or just get a general request to authorize upon sign-in to a *session, that a session nonce has been signed by an associated public key (airbitz/ledger/trezor). This does not prevent data being captured on a compromised computer but prevents spends as well as access or control of your account without a commodity hardware device.

This limits the scope of a password breach since the groups responsible for that client account data will not route anything without that second factor, nor will the first hop. Further, a user could possibly through client choose a time to authorize a session. I know safe doesn’t have time per say, but every single computer on the network does, allowing for easy way to get a consensus of GMT especially if we give weight to aged nodes.

recap for clarity: User creates safeaccount. In client/launcher always has option to associate/remove association of account with second public key (*trezor etc). Once associated, all sessions initiated by the launcher MUST be signed in order to connect to network. This changes nothing about how encryption operates on SafeNet and allows for any device or enclave to protect against unauthorized access.