OSDev.org

Data protection theory

The only safe way to protect your data is to keep them away from others.
In case that your data is in public place or must be transfered over the internet, you have to encrypt them.

There are a lot of encryption methods that successfully protects your data.

One common method is something like safe box.
You have an application that creates a virtual drive (or folder, or file) and you put all your sensitive data in there.
The application uses a password to open the safe box, and its good to be keep this password only in your mind.
If the application saves the password somewhere in your pc, then its easy to be decrypted.
Good safe boxes keeps only the CRC32/MD5 of decrypted data, just to compare is decryption was success without comparing the given password with correct password.

An other method, that is the best for me, is the encryption/decryption on-the-fly.

How it works:

You create a password protected ring-0 application that hooks disk IO actions (create, open, read, write, seek, close).
Every time system is trying on of the above actions, your code will be called.
All your encrypted data will contain a signature, just to know if you have to decrypted or not.
In case that signature is missing, ignore it and return to original IO function.
In case that signature exists, depends on the function is called, you do:

Create / Open: Just keep the file handle for later usage
Seek: Just keep the file pointer
Close: Release/Clear/Delete file handle
Read: Read file. Decrypt the data direct into given memory buffer.
Write: Encrypt the data from given memory buffer. Write file.

So, your application is between the system and the applications.
All the time the data that is on the disk is encrypted.
Decrypted data are only in memory.

If someone tries to copy a protected file to floppy/CD/whatever, the written file will be encrypted.

There is only one way to make a decrypted copy of this kind of protected file, in case this is a document.
You must have physical access to this computer and the decryptor must be enabled. Then just open the document and print it to paper.

The above encryption method is also applicable to video/audio files

This would need to be done at the filesystem layer.

I don't understand how you're solution is different than already provided ones:

Vista/XP - provide the ability to encrypt individual files

Linux - encrypts at the block device layer, so the entire file system is obscured

Both these systems do not write decrypted data on the disk.

What do you mean by lock box? What is your criticism?

If you copy an encrypted drive, it is encrypted - you must have the private key. You can store the private key on the computer (with a passphrase, as you described), or place it on another physical media, setup an internet keyserver.... (many things are possible here)...

Other problems you might want to think about:
- keeping memory areas encrypted except for current places in use
- encrypting swap/buffers/cache
- data transfers

Fate wrote:This would need to be done at the filesystem layer.

I don't understand how you're solution is different than already provided ones:

Vista/XP - provide the ability to encrypt individual files

Linux - encrypts at the block device layer, so the entire file system is obscured

Both these systems do not write decrypted data on the disk.

The difference between these encryption methods is that my method is File System in depended. You can use it in floppy/CD as well.

Fate wrote:What do you mean by lock box?

Application that stores many files in one (like zip/rar) encrypted, with user friendly interface for easy usage (works like a virtual drive).

Fate wrote:If you copy an encrypted drive, it is encrypted - you must have the private key. You can store the private key on the computer (with a passphrase, as you described), or place it on another physical media, setup an internet keyserver.... (many things are possible here)...

No. You don't need to store passwords/keys.
You give the password once you start your decrypter and this password is never checked/compared.
You just decrypt the data with the given password/key.
You only keep the CRC32/MD5 of the decrypted file to check if decryption done correct.

Fate wrote: Other problems you might want to think about:
- keeping memory areas encrypted except for current places in use
- encrypting swap/buffers/cache
- data transfers

I cannot see any problem except the data transfers (if you mean over network).
You must "see" if your file is going to the network card to filter it somehow.

On the fly drive encryption and encrypted "vaults" or "boxes" is old hat tech. There are commercial products available for all of those. Windows has had encrypting filesystem support since XP.

http://technet.microsoft.com/en-us/libr ... 57065.aspx
http://en.wikipedia.org/wiki/BitLocker_Drive_Encryption
http://www.safeboot.com/products/endpointencryption/
http://www.safenet-inc.com/products/dat ... tdrive.asp

Jef wrote:You don't need to store passwords/keys.
You give the password once you start your decrypter and this password is never checked/compared.
You just decrypt the data with the given password/key.
You only keep the CRC32/MD5 of the decrypted file to check if decryption done correct.

I didn't quite get the concept, but this looks like a pretty weak point. Does this mean that, once the user "logged in", anyone / anything running under that user's account can read all encrypted data?

This was a project before 8 years.
Our systems was win9x/Me and winNT.
At win9x was a VxD that do this job (sys for NT) and it works fine.
The code is not written whole by me, so i cannot upload the source code.
I was not participate to the version for NT, so i have no code for it.

The usage of this, it was:
You going to your office. You open your pc, and you put your password at the decryptor. The you use all your files (without care if its encrypted or not).
When you leave your pc, shuts down the decryptor and nobody can use your private files. But before leaving, you take a backup in a floppy/cd/memory stick (which also encrypted) and go home.
At home, you activate the decryptor (that can have different password because decryption algorithm was into data) and you can continue working your project/documents etc.

This project was using the dynamic & variable code generation that i explain here: http://www.osdev.org/phpBB2/viewtopic.php?t=16053

Jef wrote:No. You don't need to store passwords/keys.
You give the password once you start your decrypter and this password is never checked/compared.
You just decrypt the data with the given password/key.
You only keep the CRC32/MD5 of the decrypted file to check if decryption done correct.

In which case you're key is likely going to be really short, easily cracked, and laughable to anyone skilled in this stuff. Why keep the CRC32/MD5? It just gives an attacker one more method to brute-force decrypt your data.

Is you're goal here data protection? Because, if it is, you aren't going to succeed against any skilled.

As was already noted, the 'filesystem' based decryption has existed for a while now.

Fate wrote: Other problems you might want to think about:
- keeping memory areas encrypted except for current places in use
- encrypting swap/buffers/cache
- data transfers

I cannot see any problem except the data transfers (if you mean over network).
You must "see" if your file is going to the network card to filter it somehow.

[/quote]

These were problems you could think about better ways of doing using current known-good algorithms. The first 2 don't have ready implementations on all operating systems, the last has a ready implementation but is an interesting problem to get working.

Why keep the CRC32/MD5? It just gives an attacker one more method to brute-force decrypt your data.

Keeping the CRC32 is helpfully for sensitive front-end application, just to not be crashed if got garbages.
It's not necessary to keep it.

As was already noted, the 'filesystem' based decryption has existed for a while now.

Can be used on FAT12/CDFS? NO
Can be portable to unix/linux file systems ? NO
So ?