Write-only encrypted filesystem for transaction transportation

[oakpacific]

There are several write-only encrypted filesystem using asymmetric encryption out there, I wonder how practical it's to use them for Armory offline transactions? Only pubkeys will be entered on the online computer, so even if the malware can write itself into the filesystem, without knowing the internal structure of it, it will have a very low chance ending up somewhere executable.

[1714932969]

1714932969

[oakpacific]

Nobody interested in discussion?

[flipperfish]

Nobody interested in discussion?

Actually, I am.
I've seen your post a few days ago, but I wanted to give myself some time to think about it. My conclusion so far is, that it will not stop uber-malware, which infects the pendrive's firmware. But as I still don't know if I should take this kind of danger for real or not, we should leave it aside for now. So, the write-only fs could prevent malware on the filesystem-level, if the malware is not specifically targeted at the write-only fs. However, if there is a known vulnerability in the write-only fs, it doesn't matter that the malware can't be read back on the online pc. The online pc still can write to the write-only fs. And as soon as the malware is decrypted on the offline machine, it can be executed. The point where I'm still unsure about is, if the write-only fs has to read and decrypt parts where malware could hide in order to decrypt the transaction.

[oakpacific]

Nobody interested in discussion?

Actually, I am.
I've seen your post a few days ago, but I wanted to give myself some time to think about it. My conclusion so far is, that it will not stop uber-malware, which infects the pendrive's firmware. But as I still don't know if I should take this kind of danger for real or not, we should leave it aside for now. So, the write-only fs could prevent malware on the filesystem-level, if the malware is not specifically targeted at the write-only fs. However, if there is a known vulnerability in the write-only fs, it doesn't matter that the malware can't be read back on the online pc. The online pc still can write to the write-only fs. And as soon as the malware is decrypted on the offline machine, it can be executed. The point where I'm still unsure about is, if the write-only fs has to read and decrypt parts where malware could hide in order to decrypt the transaction.

Yes, you have  a good point, do you know how on-the-fly disk encryption program http://en.wikipedia.org/wiki/On-the-fly_encryption manages to retreive and decrypt files per demand, as everything including the metadata are supposed to be encrypted in the first place? Are metadatas for all the files stored in the same place and have to be loaded entirely each time, or the metadata for each file is accessed separately?

BTW, your project is super interesting!

[flipperfish]

Yes, you have  a good point, do you know how on-the-fly disk encryption program http://en.wikipedia.org/wiki/On-the-fly_encryption manages to retreive and decrypt files per demand, as everything including the metadata are supposed to be encrypted in the first place? Are metadatas for all the files stored in the same place and have to be loaded entirely each time, or the metadata for each file is accessed separately?

AFAIK for common disk-encryption systems the encryption happens on the block-level. The filesystem itself is also stored in some blocks (which in turn are encrypted by the encryption system as any other block). So I would assume, the code of the filesystem doesn't even notice the encryption in this case. However a write-only fs should work differently, because the writing side can't access the filesystem to look for free blocks.

BTW, your project is super interesting!

I think you mean my "PrivCoin"-Project? It's currently a bit outdated and I would currently recommend against using it. Incidentally, I also removed the link from my signature just today.

[Ente]

Wait, what's a "write only" fs? Never heard of that. Probably something like encrypting something with the public key of someone else, where even the sender can't decrypt/read the message afterwards?

Of what use it that here? The infected online computer has to have write access, and the secure to-be-infected offline computer needs read access (for the first part of the signing). With that, the malware will be able to reach the offline computer no matter what. The question is to prevent it from executing on the offline machine. After that, with both machines infected, all is lost anyway.

I may be missing something here?

Ente

[oakpacific]

Wait, what's a "write only" fs? Never heard of that. Probably something like encrypting something with the public key of someone else, where even the sender can't decrypt/read the message afterwards?

Of what use it that here? The infected online computer has to have write access, and the secure to-be-infected offline computer needs read access (for the first part of the signing). With that, the malware will be able to reach the offline computer no matter what. The question is to prevent it from executing on the offline machine. After that, with both machines infected, all is lost anyway.

I may be missing something here?

Ente

You can create a big partition, filled by lots and lots of files, unknown to any program on the online computer, so the malware on the online computer, without knowledge of the underlying structure of the FS, should have a very slim chance of putting itself somewhere auto-executable(on the contrary it may even make the filesystem unmountable by overwriting some essential metadatas) after the decryption, as the space allocation is not contiguous and linear. Armory, otoh, could be instructed to write transaction data to some designated places, to be recovered later.

[Ente]

Wait, what's a "write only" fs? Never heard of that. Probably something like encrypting something with the public key of someone else, where even the sender can't decrypt/read the message afterwards?

Of what use it that here? The infected online computer has to have write access, and the secure to-be-infected offline computer needs read access (for the first part of the signing). With that, the malware will be able to reach the offline computer no matter what. The question is to prevent it from executing on the offline machine. After that, with both machines infected, all is lost anyway.

I may be missing something here?

Ente

You can create a big partition, filled by lots and lots of files, unknown to any program on the online computer, so the malware on the online computer, without knowledge of the underlying structure of the FS, should have a very slim chance of putting itself somewhere auto-executable(on the contrary it may even make the filesystem unmountable by overwriting some essential metadatas) after the decryption, as the space allocation is not contiguous and linear. Armory, otoh, could be instructed to write transaction data to some designated places, to be recovered later.

In theory, yes.
We are speaking of a highly targeted armory-infecting malware here. Armory is open-source, for good reason. The malware author would know what files/sections Armory uses, and would ignore the bogus other file/area. Security by obscurity isn't a good solution, and always a bad solution when the stuff is public ;-)

Also, malware would either have to make use of an unknown bug in Armory which executes code, or an unknown bug in the (linux?) OS of the offline computer while mounting the USB stick.
I guess absolutely nothing helps against these two vectors, if exploitable bugs are known to the attacker.
We could make the transferred data a limited length, or even better, human-readable. This would make an attack more difficult, but still not impossible.
As long as we transfer data in both directions, there can't be provable/100%/total security.

If there is a way to make sure my offline linux box won't be infected by a USB stick when I plug it in, totally independent to the whole Armory scenario, I am satisfied. As long as I am not the target of real humans, that is..

Ente