I successfully use TrueCrypt in order to protect my source code.

TrueCrypt creates a password protected crypted disk in my PC.

I can freely leave my PC unattended: nobody will be able to steal my code.

However when my PC is connected to a net, I cannot be so confident.

In fact when the crypted disk is mounted by windows, everybody connected to my PC can read (and possibly steal) disk data.

I wonder if some software product X exists where the a crypted disk is NOT mounted by the OS but _by the application_

2 applications using X should be able to concurrently read/write dato from/to the crypted disk.

Any application not using X should see only a fixed size (2GB?) file.

Does this product exist ?

It should be possible to use it from a pascal or delphi application.

Thank you
Duilio

In theory something like this could exist (I'm not aware of anything for TrueCrypt protected files), but having two or more applications that concurrently write to a single file is a bad(TM) idea. Imagine both applications want to write to the end of the file at the same time. Which application's content will then be in the file? Maybe that of the first one. Maybe that of the second one. Maybe a mix of both. Especially in the last case you can consider the file corrupted. If two or more applications should access a file in a writeable manner they should go trough a third "service" which controls accesses and writes to the file (like is usually done with e.g. databases). And simply spoken the OS is such a kind of service (though its not running as a separate process per se). Another possiblity would be to have a real service...

A little bit more on the topic of "world writable files": http://blogs.msdn.com/b/oldnewthing/archive/2004/11/22/267890.aspx

Regards,
Sven

Btw. a little information regarding TrueCrypt:

http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/

Regards,
Torsten.

but having two or more applications that concurrently write to a single file is a bad(TM) idea

all operating systems and all db services like VirtualBox, Firebird etc allow that.

The product I look for must be smart enough :)

Thank you
Duilio

2014-08-13 7:42 GMT+02:00 Sven Barth :

Btw. a little information regarding TrueCrypt:

TC is secure enough for my needs.

Thank you
Duilio

2014-08-13 7:56 GMT+02:00 Torsten Bonde Christiansen :

duilio foschi wrote

> Btw. a little information regarding TrueCrypt: TC is secure enough for my needs.

NSA is very happy :-)

duilio foschi wrote

> but having two or more applications that concurrently write to a single file is a bad(TM) idea all operating systems and all db services like VirtualBox, Firebird etc allow that.

(1) Operating systems may allow you to access files from more than one process, but they do not guarantee that this doesn't ruin your files in terms of making inconsistent changes. On encrypted files, especially large ones, the damage would be even worse (i.e., most likely total and highly unrecoverable).

(2) I'm not sure how VirtualBox fits in here. If you mean that it allows you to access files from host and guest system simultaneously, then see (1).

(3) Database products allow you to access DATA BASES from several processes/clients via their engine (e.g., a through a local or web service). This is entirely different from accessing FILES simultaneously from independent processes – and one of the aspects that makes writing database applications complicated.

The product I look for must be smart enough :)

I think the smartest option is to use standard available disk or home folder encryption, because it works. I doubt that DiskGlasses™ would ever work.

> Btw. a little information regarding TrueCrypt: TC is secure enough for my needs.

What? Quite honestly, I do not see why it is necessary to protect your source code in the way you want to do it, even for closed-source projects. However, if it is that important, I suggest you just encrypt your files using a piece of software which has NOT been declared insecure by its developers, or has been (even worse!) hijacked by government agencies and/or criminal elements. There are many options:

http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software

In other words, if it is really reasonable that you encrypt your source code (maybe even including plausible deniability tricks), then TrueCrypt is definitely NOT enough for your needs.

In addition to using any secure file encryption, just work offline on a computer the hardware of which (to the best of your knowledge) has not been tampered with.

Best,
Roland

duilio foschi wrote

> Btw. a little information regarding TrueCrypt: TC is secure enough for my needs.

But in that case why did you write

"In fact when the crypted disk is mounted by windows, everybody connected to my PC can read (and possibly steal) disk data." ?

If you're having to address problems like this, possibly as part of a security audit (who did you say you worked for?) then I quite simply think that you're either using the wrong type of computer system or it's set up wrong.

Your issue, as you describe it, is that anybody can set up a share on your computer such that they can read your files. That's the problem you should be addressing.

It would probably be possible to do something with streams at the application level where each stream locked the underlying file and then allowed full read-write access. But at that point you'd have to weed out all cases where multiple streams were looking at the same file, and if you really did want multiple apps to have unrestricted decrypt/modify rights then you'd effectively have to write your own operating system to do it.

Torsten Bonde Christiansen wrote

Btw. a little information regarding TrueCrypt: http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/

Given that no explanation was given regarding what exactly the supposed problems were, and given the fact that the independent audit of the last known good TrueCrypt source code (the one before that message was posted) until now has not found any issues (although they're by no means finished yet: http://istruecryptauditedyet.com/ ), it's quite possible that this whole episode was mainly FUD that the developers were forced to spread in one way or another.

Afaik the only known weakness is that if someone can get physical access to the computer while it's turned on and manage to dump its complete memory contents, they can recover the decryption key.

Jonas

"TC is secure enough for my needs" was an answer addressing the NSA paranoia :)

It would probably be possible to do something with streams...

the product I need is clearly hard to code.

If no solution "prêt à porter" exists, I will pass :)

I imagine magic glasses.

In a room, only the few people who wear the magic glasses can see data inside a box.

The rest (who have no magic glasses) only see the box.

Brought to IT, only applications that use product X will "see" disk Y (and be able to read/write data into it).

The rest of applications only see a fixed size file.

Thank you

Duilio

2014-08-13 11:04 GMT+02:00 Mark Morgan Lloyd
:

On Wed, August 13, 2014 11:35, duilio foschi wrote: .
.

The standard solution provided by existing operating systems is "simple" - make sure that these applications run under different users and that the users have appropriate access rights.

Obviously, this implies that implementation of such operating systems is sufficiently secure itself (i.e. ensuring the designed level of protection and thus not allowing others to get unauthorized access to the respective resource), but that equally applies to any other solution as well (including whatever "product X" - either you trust it, or not).

Now - if you don't trust that e.g. certain operating system from certain large software company is sufficiently safe regarding protection from unauthorized access over the network (specifically), you could for example improve the security by adding some additional protection mechanisms in between - run the whole operating system in a "walled garden" e.g. through virtualization of the operating system instance including the encrypted disk and applications having access to the respective data, run it in private LAN not directly addressable from outside and ensure only secured access is possible, etc. In any case, the most appropriate solution must be designed according to the full list of requirements which has not been provided.

Tomas

Just a view notes on your fine contribution:

File access is more a matter of network and *file systems*, the OS only must provide minimum support (integration...) for such extensions. That's the way how e.g. file and volume encryption is implemented.

Concurrent file operations and file integrity is left to the file user (processes). The OS provides file locking mechanisms, but the user can allow or deny concurrent file access when opening an file. Similarly the user (admin) can specify access rights on volumes or files, the OS and file systems only provide such managment features.

(2) I'm not sure how VirtualBox fits in here. If you mean that it allows you to access files from host and guest system simultaneously, then see (1).

Virtual Machines typically offer network connections, which allow for file access in both directions. Again it's the user (admin) who grants access rights, establishes shares etc. The user can effectively "unplug" the network connections of a VM, so that no data can be transferred into (viruses...) or out of (file copy...) a VM. But it should be kept in mind that the volumes of a VM are stored as drive image files on the host machine, so that these files also must be protected against attacks (by access rights). Encryption can be applied to the file system(s) inside the VM, then the disk images on the host machine contain encrypted information, and no further encryption is required then.

Databases come in single-user or multi-user flavors. Multi-user databases typically use a client-server model for data access, where the server handles concurrent requests from the client processes. While a single-user DB software protects the DB files only while the DB is used by an process, a multi-user DB may establish a permanent lock, once a server has been started.

I've used an similar mechanism already, by opening a couple of critical files in a dedicated application, so that these locked files could not be replaced by other processes. That application could disallow read access as well, but then it should become a file server, because otherwise no other user program could use the locked files.

DoDi