Improving Offline Wallets (i.e. cold-storage)

[gglon]

That's probably the best way for "regular users" with fat wallets. As long as you can trust the (source of the) livecd, it is pretty tight. And has the bonus that it doesn't need a dedicated hardware.
I prefer a dedicated hardware which makes everything quick and easy, once it is setup. I think the "market" for your solution is bigger though.

Thanks for your support, since I was thinking about bitcoin security for past few days and it wasn't that easy for me to figure it out. Still, I don't know if it hasn't been proposed earlier. I think this proposal may compete with hardware wallets pluged to standard pc, as it is cheaper and a normal keyboard/screen is much more comfortable. While distribution of livecd would be even more secure that hardware, as you can easily download it from trusted source like mt.gox or theymos and verify.

[1713980868]

1713980868

[1713980868]

1713980868

[Lavender]

1. run livecd with preinstalled software

Any suggestions on how to create a liveCD with preinstalled software? I'm familiar with making LiveCDs, but not with the preinstalled software portion.

EDIT: I found a better way, thanks to N.Z.'s post. I have created a hyperlinked Google word document tutorial (whose formatting was too much trouble to get embedded here).

[drazvan]

Etotheipi mentioned QR codes in his initial post and we've tried to work around the "minuses" he's mentioned for sending/receiving data that way. What we've come up with is VisualBTC - I've posted a thread on it here: https://bitcointalk.org/index.php?topic=210371.0 .

It uses animated QR codes to send/receive data (update unspent outputs list and post transactions). The private key never leaves the device and it's never connected to the Internet (WiFi chip can even be disabled in the bootloader on the suggested hardware - a $50 capacitive-screen 4.3 inch Android tablet, see the original thread for more details).

[neoranga]

Sending large amounts of data using QR-codes is a pain. However, you can compress an unsigned transaction pretty well is both sides agree on a simple protocol.

...

Unless I have forgotten something crucial this should work.

Unfortunately, it can't be that simple.  In fact, even for the simple case you describe, it is dramatically more complex.  Why?  Allow me to explain how offline wallets work in Armory, and why data sizes will never be that small.

Satoshi decided not to include the input values of the inputs being spent in the transaction inputs or explicit declaration of the fee in the transaction data to be signed.  This sounds arbitrary, because that information is located in the blockchain, so the node only needs to go look it up the OutPoints in the blockchain to know.  Right?   Well, offline wallets can't do that.  And part of the value of Armory for offline transactions is that the offline computer doesn't need the blockchain.  You might say "okay, well just throw that information in with the tx to be signed so that the offline computer knows."  If only it were that simple...

gmaxwell expressed concern, rightly, that if your online computer is infected, the next transaction you make might have a devastatingly malicious modification:  it completes your transaction, but sends the rest of the balance of your wallet to transaction fee.  But you don't know this, because the attacker also modified the "supplementary" information in the transaction, so that the offline computer thinks it's only signing a 1.01 BTC input, with 0.5 to recip, 0.5 to change, and 0.01 to fee.  But the attacker actually put a 300 BTC input on the tx-to-be-signed, but put in the "supplemental" information that the input is only 1.01 BTC.  The result will be the offline computer showing you that you are sending 0.5 BTC to the recipient with 0.01 fee.  But when you send the transaction, it's actually 299 BTC fee.

THEREFORE:  my BIP 0010 "protocol" includes the entirety of each transaction which supplies inputs to the transaction-to-be-signed.  For each input in the tx-to-be-signed, Armory sees the OutPoint (txHash, txOutIndex), and verifies that it was passed a transaction with the same TxHash.  From that transaction, it can verify the value of the input and the final tx fee. 

• If the attacker changes the recipient or the amount sent to recipient -- the user should notice because they can see the list of recipients and values before they sign it
• If the attacker changes the value specified on the supplementary tx -- the suppl tx hash will no longer match the OutPoint on the tx-to-be-signed, verification will fail
• If the attacker changes the supplementary tx value and the OutPoint hash -- the transaction is no longer valid, because that OutPoint doesn't actually exist

In fact, that pretty much clears up every possible avenue for tricking the offline computer.  Now, every piece of important information is verifiable by the offline computer.  If there is manipulation, the either the tx won't be valid, or the user will notice when they look at the transaction details.


Okay, so that gets us back to the original question of "how much data do we have to transfer between online and offline computer?"  Unfortunately, the simplest case is not relevant to this discussion:  you have to design the protocol around the 99.9'th percentile case:  which is the case that someone has an offline donation address that they want to clear out.  Let's say they have received 40 donations.

So the transaction will have 40 inputs and 2 outputs. 

The bulk of the data is the supporting transactions which can be anything (transactions created by the donors).  Each one itself may have dozens of inputs, and the signatures are necessarily included!  Let's assume 30 "standard" supporting transactions, and the other ten have 10 inputs each.

• Tx-to-be-signed:  30 inputs (unsigned) of 48 bytes each, and two outputs of 40 bytes each = 1.5 kB 
• 30 standard supporting tx:  250 bytes each = 7.5 kB
• Ten larger tx:  180 bytes for each input (signed), so about 2 kB each = 20 kB

So the online computer needs to communicate 30 kB to the offline computer in this case.  And the offline computer needs to transfer back 30 signatures, which is, at best, 2 kB at a minimum.  The "maximum" a QR code can handle is 3 kB of binary, so that's 10 QR codes from online to offline.  1-2 QR codes the other way.

So the protocol should handle 30 kB without causing a lot of pain.  If the user has to wait a little bit because of a slow communication rate, that's okay because this case is abnormal and waiting 60s for the transfer isn't the end of the world.  But if they can't succeed because it's confusing and they can't figure out how many and which QR codes have been scanned, or which webcam they're supposed to be pointing at which device, and frustrated there are wires everywhere, etc.  Then there's a problem...

As you can tell, I'm very sensitive to the "convenience" of a given feature.  I think the biggest barrier to security is convenience -- users just don't use things that are inconvenient.  But I also don't want to sacrifice security, at all, no matter how much work it is for me.  Which is why there are so many recommendations here that are great, but don't quite the bill.  But I'm pretty sure a solution exists where the user can actually have both, in which case everyone wins

Hi etotheipi,
I also had the same idea of using QR codes to transfer data between online and offline machines but I have a very specific use case that should solve the transaction size problem, using a unique input address in the cellphone as a small wallet to pay on a merchant's point of sell where the cellphone doesn't have network connection.
I have described the use case here: https://bitcointalk.org/index.php?topic=230010
Do you think this is feasible?

I would like to implement the idea in a light phone client in combination with a full client like Armory used as merchant's POS to broadcast the transaction.
Armory could provide all the elements for the transaction in a QR code and send to phone:
- Merchant's payment address
- Information required for the transaction from the blockchain, including fees
The thin client will take:
- Ingredients from Armory QR code
- Put together with the unique wallet address
- Sign transaction
Then present all information requesting user to confirm transaction details (including fee) and then send the QR code with full signed transaction back to Armory to be broadcast.

[flipperfish]

I don't know if this has been proposed already, but would it be possible and/or improve the security to transfer the unsigned transaction to the offline PC on a write-locked medium (like USB drive with write-lock-switch or CD) and then use QR-codes to transfer back only the signatures? This way the only possibility for the private keys to get out of the offline PC would be the QR-codes. This should be detectable pretty early, because the QR-code would be bigger than normal. For most transactions 1-3 QR-codes should be enough (and if iQR-codes will be availiable, a single code should be sufficient for a majority of the cases).

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc. The online pc then matches the signature to the unsigned transactions. No webcams (besides in the smartphone) are needed this way. Even single-machine setups using a live-cd for the offline part could use this as the smartphone could act as an intermediate storage for the signature until the single machine has rebooted into online mode.
The smartphone can also act as an additional security layer, if it does some simple plausability checks on the data received through the QR-code. So even if the malware on the online pc makes it to the offline pc and tricks armory into putting the private keys into the QR-code, the smartphone would notice and prevent the data from going back to the infected online pc. So for this scenario to be fruitful for the attacker, he needs to also compromise the user's smartphone in addition to the online pc and the offline pc.

[oakpacific]

I don't know if this has been proposed already, but would it be possible and/or improve the security to transfer the unsigned transaction to the offline PC on a write-locked medium (like USB drive with write-lock-switch or CD) and then use QR-codes to transfer back only the signatures? This way the only possibility for the private keys to get out of the offline PC would be the QR-codes. This should be detectable pretty early, because the QR-code would be bigger than normal. For most transactions 1-3 QR-codes should be enough (and if iQR-codes will be availiable, a single code should be sufficient for a majority of the cases).

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc. The online pc then matches the signature to the unsigned transactions. No webcams (besides in the smartphone) are needed this way. Even single-machine setups using a live-cd for the offline part could use this as the smartphone could act as an intermediate storage for the signature until the single machine has rebooted into online mode.
The smartphone can also act as an additional security layer, if it does some simple plausability checks on the data received through the QR-code. So even if the malware on the online pc makes it to the offline pc and tricks armory into putting the private keys into the QR-code, the smartphone would notice and prevent the data from going back to the infected online pc. So for this scenario to be fruitful for the attacker, he needs to also compromise the user's smartphone in addition to the online pc and the offline pc.

But if the malware manages to control both Armory instances on the offline and the online computers, then they can make you supplying the online instance a signature signing a transaction created in secret to the attacker's address, while showing you the normal one on the screen......

[flipperfish]

I don't know if this has been proposed already, but would it be possible and/or improve the security to transfer the unsigned transaction to the offline PC on a write-locked medium (like USB drive with write-lock-switch or CD) and then use QR-codes to transfer back only the signatures? This way the only possibility for the private keys to get out of the offline PC would be the QR-codes. This should be detectable pretty early, because the QR-code would be bigger than normal. For most transactions 1-3 QR-codes should be enough (and if iQR-codes will be availiable, a single code should be sufficient for a majority of the cases).

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc. The online pc then matches the signature to the unsigned transactions. No webcams (besides in the smartphone) are needed this way. Even single-machine setups using a live-cd for the offline part could use this as the smartphone could act as an intermediate storage for the signature until the single machine has rebooted into online mode.
The smartphone can also act as an additional security layer, if it does some simple plausability checks on the data received through the QR-code. So even if the malware on the online pc makes it to the offline pc and tricks armory into putting the private keys into the QR-code, the smartphone would notice and prevent the data from going back to the infected online pc. So for this scenario to be fruitful for the attacker, he needs to also compromise the user's smartphone in addition to the online pc and the offline pc.

But if the malware manages to control both Armory instances on the offline and the online computers, then they can make you supplying the online instance a signature signing a transaction created in secret to the attacker's address, while showing you the normal one on the screen......

That's a valid point, I didn't think of, thanks for mentioning!
But the smartphone intermediate step should help. As long as the smartphone is not infected it still could verify the signature against the original transaction. Let's assume the malware on the online pc managed to get a malicious transaction onto the pendrive and the user did sign it on the offline pc, because armory was tricked into showing him the original transaction. Now the signature of the malicious transaction will be transfered to the smartphone. The smartphone acquires the original transaction from the online pc and checks the signature against the transaction. Now, because the online pc sent the original transaction, but the offline pc sent the signature for the malicious transaction, the verification will fail. On the other hand, if the online pc sends the malicious transaction, a careful user would notice the change on the smartphone.

I think the important part is indeed the intermediate check on the smartphone. The qr code for returning the signature alone won't defend against malicious transactions (as you pointed out).
However, since the smartphone still is connected via wifi it probably can be compromised rather easily, too. Nevertheless it increases the complexity for the attacker, while the complexity for the user doesn't increase that much.

[oakpacific]

I don't know if this has been proposed already, but would it be possible and/or improve the security to transfer the unsigned transaction to the offline PC on a write-locked medium (like USB drive with write-lock-switch or CD) and then use QR-codes to transfer back only the signatures? This way the only possibility for the private keys to get out of the offline PC would be the QR-codes. This should be detectable pretty early, because the QR-code would be bigger than normal. For most transactions 1-3 QR-codes should be enough (and if iQR-codes will be availiable, a single code should be sufficient for a majority of the cases).

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc. The online pc then matches the signature to the unsigned transactions. No webcams (besides in the smartphone) are needed this way. Even single-machine setups using a live-cd for the offline part could use this as the smartphone could act as an intermediate storage for the signature until the single machine has rebooted into online mode.
The smartphone can also act as an additional security layer, if it does some simple plausability checks on the data received through the QR-code. So even if the malware on the online pc makes it to the offline pc and tricks armory into putting the private keys into the QR-code, the smartphone would notice and prevent the data from going back to the infected online pc. So for this scenario to be fruitful for the attacker, he needs to also compromise the user's smartphone in addition to the online pc and the offline pc.

But if the malware manages to control both Armory instances on the offline and the online computers, then they can make you supplying the online instance a signature signing a transaction created in secret to the attacker's address, while showing you the normal one on the screen......

That's a valid point, I didn't think of, thanks for mentioning!
But the smartphone intermediate step should help. As long as the smartphone is not infected it still could verify the signature against the original transaction. Let's assume the malware on the online pc managed to get a malicious transaction onto the pendrive and the user did sign it on the offline pc, because armory was tricked into showing him the original transaction. Now the signature of the malicious transaction will be transfered to the smartphone. The smartphone acquires the original transaction from the online pc and checks the signature against the transaction. Now, because the online pc sent the original transaction, but the offline pc sent the signature for the malicious transaction, the verification will fail. On the other hand, if the online pc sends the malicious transaction, a careful user would notice the change on the smartphone.

I think the important part is indeed the intermediate check on the smartphone. The qr code for returning the signature alone won't defend against malicious transactions (as you pointed out).
However, since the smartphone still is connected via wifi it probably can be compromised rather easily, too. Nevertheless it increases the complexity for the attacker, while the complexity for the user doesn't increase that much.

My gut feeling is that your proposal is  a big step in the right direction, which has the potential to achieve ideal security, so we should not only be satisified with " increases the complexity for the attacker".

[Ente]

That's an interesting topic.
So now we have two or three or more computers. We don't know what data they are exchanging. We know how much data they are exchanging. We can control who talks to whom, in what order. All computers need to send and receive data. We will not notice once one computer is infected. Oh, and we can watch from outside if the transaction, finally, did what was expected, or cleared the whole wallet ;-)

I believe even such a secure, complicated setup would not hold up against an attacker with deep pockets. But then, those attackers will do stuff like stuxnet, and not waste ressources on a project where the stolen funds are only a fraction of the costs.
If those attackers had Bitcoin set as a target, I know a few places where there would be more funds to steal ;-)

So, for me, I will stick to an offline computer, livecds and regular operation security. That is not absolutely secure. But I am a higher hanging fruit than a lot of users.

I enjoy these topics. We have to define the extremes, to find out where a reasonable balance would be, not?

Ente

[gokudev]

i didn't see this explicitly stated in the thread, but is the goal with using serial ports for communication to avoid firmware exploits on the NICs?

never a good idea to store valuable data on a machine that doesn't use disk crypto, it has saved my ass on several occasions.

The disk crypto doesn't help in this case, because either (1) you use full-disk-encryption, which will be unlocked while the system is on, so a "copy" will copy the unencrypted data, or (2) The wallet file is encrypted only, in which they only need to keylog your passphrase to get it.  Though, I have received some good ideas for helping with keylogging, but any malware advanced enough to compromise your offline computer could easily pull your crypto key out of RAM next time you unlock the wallet. 

The goal is to avoid getting to that point at all:  a serial connection that doesn't possibly induce any subsystems to kick in and try to help out.

suffice it to say i have spent many moons doing computer security work and i cannot get a good idea of what your threat model is here.

in order to spend your coins, at some point the corresponding wallet must be on a computer, which i am assuming is offline in your threat model. in order to have some reasonable assurance that the computer's drive has not been tampered with while off, presumably stored in a safe or similar, you should use disk encryption. to suggest that disk encryption doesn't help reduce the chance of a compromise here is incorrect, afaict.

of course, if your machine is rooted, the attacker has DMA. the usual means of defeating keyloggers is authentication tokens, but that is only of limited use on an offline machine.

I never said that disk encryption is pointless.  But Armory already encrypts your wallet, and guarantees that if your wallet is created encrypted, the unencrypted keys never touch the disk.  By all means, you need encryption, but full disk-encryption is mostly redundant here.  In fact, in some environments, it's inferior -- if you were to use full-disk encryption and unencrypted wallet files, then you are protected the same when your computer is off but the encryption is completely useless while the computer is on (so it can run the OS and access your files).  Someone who gets on your compute for 1 minute can put in a USB key, and copy off the [unencrypted] wallet file to their key.  Ditto for serial.    At least with Armory encryption, the file on disk is always encrypted and inaccessible even when the computer is unlocked. 

The counterpoints to these thoughts are:  just hedge and use both -- disk encryption and Armory encryption.  And in the end it may not matter--anything advanced enough to get to your offline system is probably advanced enough to pull your private keys out of RAM when you unlock your wallet to sign a transaction.  No disk encryption can protect against that.

The security environment is this:  you have an offline computer setup securely, and it has not been compromised in any way.  You have a verified version of Armory installed and know it works perfectly (of course).  However, you assume an attacker has full control of your online computer, and knows you will be using <insert transfer method here> to move data back and forth between your [compromised] online computer, and you're not-yet-compromised offline computer.

If it's a serial connection that's not done correctly, they grab your Firefox password file and try every entry to TTY login to the offline machine.  Once there, they grab the encrypted wallet, and start trying to brute force it (probably also related to one of your firefox passwords...).  Or if that's not enough, they keylog your passphrase and send it back over the serial line to the online computer (which is compromised).

Similarly, if your transfer method is USB keys, there's undoubtedly lots of ways to exploit autorun.  Put a carefully crafted file on the USB key with a payload that gets executed when you plug in the USB key, and it carries your wallet out with it when the user brings the USB key back to their online computer. 

Any mention of Armory flaws, or initial install security is mostly out-of-scope.  We assume the user installed the correct software offline and that the software itself performs exactly as expected. 

I just want to point out, most virus protection software will pickup any malicious executable from running and will stop it from executing unless approved by the user. Memory hacks, especially calling any low level hooks, keyloggers can be easily caught by virus scanners. avg does pretty good job.

[Ente]

I just want to point out, most virus protection software will pickup any malicious executable from running and will stop it from executing unless approved by the user. Memory hacks, especially calling any low level hooks, keyloggers can be easily caught by virus scanners. avg does pretty good job.

I strongly disagree.
Antivirus software does a lousy job in protecting from malware.
It gives the user a false sense of security, maybe leading to more risky behavior.
It eats a whole lot of performance.

Good read on this:
http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet_operator_ama/

In short, consider your system compromised. And use a second system for bitcoin-only. An old 100$ netbook, a trezor, or even an old smartphone if you must. At least consider that as soon as your Bitcoin holding is non-trivial. The Armory wallet is your friend, by the way.

Well, that topic is a whole universe in itself..

Ente

[gokudev]

I just want to point out, most virus protection software will pickup any malicious executable from running and will stop it from executing unless approved by the user. Memory hacks, especially calling any low level hooks, keyloggers can be easily caught by virus scanners. avg does pretty good job.

I strongly disagree.
Antivirus software does a lousy job in protecting from malware.
It gives the user a false sense of security, maybe leading to more risky behavior.
It eats a whole lot of performance.

Good read on this:
http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet_operator_ama/

In short, consider your system compromised. And use a second system for bitcoin-only. An old 100$ netbook, a trezor, or even an old smartphone if you must. At least consider that as soon as your Bitcoin holding is non-trivial. The Armory wallet is your friend, by the way.

Well, that topic is a whole universe in itself..

Ente

That is a common reputation given to most antivirus software, I used to think antivirus would do a crap job too in finding malware. But they are pretty good in marking a exe as a false positive and then preventing execution all together. Using behaviour patterns, an antivirus can help prevent running a not so recognized binary, a good antivirus can mark a binary as false positive, for example if it tries to call CreateProcess or try to hijack LSASS.exe or something out of the norm. Then ultimately it comes down to the user to give access.

I like the idea of using Raspberry Pi Model A as a second system. It is cheap to buy and has no ethernet port. any updates to the device can be done by getting a cheap usb to ethernet dongle. I still need to figure out a less manual way than using usb keys to transfer data between offline and online storages.

etotheipi pointed out IR stream would be 100% secure. I am curious to know if there is an implmentation available to test out.

[softron]

Very useful guide. Thanks

[Brangdon]

This is why I recommend using an ancient about-to-be-junked laptop.  I got a throwaway from work for free. You can get something on ebay or craigslist for about $50.  Anything with 256 MB of RAM or more will run Armory in offline mode.  Most users will have no interest in using a slow-as-dirt laptop that can hardly load a browser, for anything else but cold storage.

Having done this recently, one practical hurdle I found was getting a Linux distro that would run on the offline device, and then getting Armory to run on that distro. I gave up on the first step after a few failed attempts, partly because I figured that for the second step, I'd need to rebuild Armory from source, and it seemed like too much hassle, especially if the rebuild was to happen on the offline computer.

(Getting a clean WinXP isn't easy now either, since Microsoft have long stopped selling it and I wouldn't trust a third party distro not to come with keylogger pre-installed.)

-- I think the best idea mentioned is the secure Armory OS.  Build it off of something small and stable.  No dependencies on any software the Armory team hasn't written or inspected.

That does sound like a good approach. It should be simplest for the user (provided the cut-down distro would run on almost anything) and wouldn't involve extra hardware or faffing about getting the machines to see/hear each other.

One drawback for me is that I'd presumably lose the ability to use my password manager. Currently I have the same password database on both online and offline machines, so a shared master password. I believe a password manager is crucial for practical password-based security, and I'd rather not have to learn a password just for Bitcoin. So being able to run certain 3rd party software on the offline machine can be helpful.

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc.

Using a smartphone intermediary could be more convenient for QR codes. It'd be easier to hold the smartphone so its camera can see the online computer's screen than to hold a laptop, and easier to move between devices if they are on different desks.

Even better might be to use the smartphone as the offline computer. Old smartphones are almost as common as old laptops. Take the SIM out and switch off networking, and use either QR codes, sound or a micro-SD card for I/O. Alternatively combine this with the previous approach, and have a custom build of Android that just does Armory. Either way the small form-factor would be a bonus.

[etotheipi]

This is why I recommend using an ancient about-to-be-junked laptop.  I got a throwaway from work for free. You can get something on ebay or craigslist for about $50.  Anything with 256 MB of RAM or more will run Armory in offline mode.  Most users will have no interest in using a slow-as-dirt laptop that can hardly load a browser, for anything else but cold storage.

Having done this recently, one practical hurdle I found was getting a Linux distro that would run on the offline device, and then getting Armory to run on that distro. I gave up on the first step after a few failed attempts, partly because I figured that for the second step, I'd need to rebuild Armory from source, and it seemed like too much hassle, especially if the rebuild was to happen on the offline computer.

The website has "offline bundles" you can use.  It has a link to Ubuntu 10.04-32bit and a bundle that you can unpack and install on the first boot of a never-touched-the-internet boot of 10.04.  you should try it out... I made it for exactly the same reasons your complaining about here

[Brangdon]

The website has "offline bundles" you can use.  It has a link to Ubuntu 10.04-32bit and a bundle that you can unpack and install on the first boot of a never-touched-the-internet boot of 10.04.  you should try it out... I made it for exactly the same reasons your complaining about here

I did try Ubuntu 10.04-32bit (I forget whether I got it from your link or elsewhere). It would not install on my device. My SSD was too small. It's a touch under 4GB. The device is an Asus EEE PC701. (It also has a small screen, 800×480.) Part of what made the attempt frustrating was a lack of documentation about what the hardware requirements actually are, but as far as I can tell most versions of Ubuntu with a GUI need at least 5GB and 800x600.

[gokudev]

Are there any problems with using a vpn connection instead of a usb ? What are some possible security risks?

[flipperfish]

Are there any problems with using a vpn connection instead of a usb ? What are some possible security risks?

If the VPN connection is based on OpenVPN, which uses OpenSSL by default, there would be for example the heartbleed bug, if it is not yet fixed on the machine you use.

[gokudev]

Are there any problems with using a vpn connection instead of a usb ? What are some possible security risks?

If the VPN connection is based on OpenVPN, which uses OpenSSL by default, there would be for example the heartbleed bug, if it is not yet fixed on the machine you use.

So windows servers are not affected by this bug. Microsoft uses something called sstp to secure vpn.

[Ente]

Are there any problems with using a vpn connection instead of a usb ? What are some possible security risks?

If the VPN connection is based on OpenVPN, which uses OpenSSL by default, there would be for example the heartbleed bug, if it is not yet fixed on the machine you use.

So windows servers are not affected by this bug. Microsoft uses something called sstp to secure vpn.

It totally depends on the software used.
But in genertal, the more complex and big a system is, the more points of failure there are. And here, we have two instead of one computer, they both are online, and you have a vpn in between. Enhanced physical security may be worth it, depending on the situation. Nice to know that noone can just break in, grab a computer, and has everything he needs.

Edit:
The important part is to distinguish two designs:
- "security measures in parallel", like a chain where you only have to break the weakest link (break one of the two computers or the VPN)
- "security measures in series", like layers where you have to break through all of them (like n-of-m, on paper wallets, encrypted)

Besides that, a "safe fallback" is good. "If anything irregular happens, it all shuts down and is fine" (like full hdd encryption for example). Also, consider every single component to be compromised. A million bonus points for designing a setup where every single component may be compromised at the same time, and you still don't lose :-)

Ente

Ente