What do you guys think of this...?

I've recently been asked to write a crypto program by a client. It's being done in VB/Access/Visual C++. So far, I've thought of something like this...

1. Use a strong symmetric cipher system like twofish or similar to encrypt the Access mdb.
2. The key is stored in multiple, persistent variables that are checked so that they aren't contiguous in memory.
3. Password protect the program and store the password as a md5 hash in two distinct places in the registry.
4. If the hashes don't match, wipe the program, but not the data.
5. If the password is entered wrongly more than x times, wipe the program, not the data
6. Store a md5 checksum of the file somewhere, maybe in the registry.
7. If the md5 checksum changes, wipe the program, not the data.
8. Since the key is stored in the program, if the right encryption scheme is used, the encrypted mdb file is useless.
9. Also, if the user accidentally deletes the program, all he has to do is reinstall the program and the mdb is decrypted.

This might seem like overkill, but the user needs this kind of security. Any thoughts on how to improve this....?
Cheers,
cgkanchi

Dunno what you are trying to protect, but I would add at least one element of the key in a removal device - USB Keyfob or similar.

The problem I can see with you system, although minor, is if the system is cloned (using Ghost or similar) to readonly media then I can brute force the password to the program, without the program being deleted, to my hearts content.

Having part of the key in a removable drive requires the ownership of the drive, as well as a clone of the system.

Steve

Storing the key in the software itself is a bad idea. Even though you have split it in memory, reverse engineering the app would reveal how and where the key is stored. so you dont really need a password at all. Perhaps creating a hash of the users password and using that as key to encrypt the .mdb, that way the data is encrypted on the secret and not the access to the app. (Or is that not what you want???)


-Maestr0

For your number 9, i would get rid of it altogether. If your client is concerned about security, don't leave a gaping hole like that. I mean, depending on what your installer does and if the attacker can get ahold of it, he could bypass all your hard work. Also inline with what others have said, use removable media for storing at least part of the key on. If the user accidentally deletes the program, have them get you to build back what's needed for security's sake.

Try something like SCRAMDISK?

Data re-encrypted with four passwords..........not immediately obvious either?

Just a thought?

why not ad a unique id, produced randomly by the installer which is written on to the usb thumb and have this id used to help decrypt the document

I thought of this too, but my client does not want removable media. I did tell him that not having the key on removable media would reduce security, but he says he can live with that. Also, from Maestr0's post, encrypting the data with the hash isn't a great idea as the hash has to be stored persistently (to check if the correct password has been entered). However, encrypting the key itself with the plain text password or a hash of the hash is a good idea. Thanks for starting that thought process...

Quote:

---

why not ad a unique id, produced randomly by the installer which is written on to the usb thumb and have this id used to help decrypt the document

---

I need the data to be recoverable by my client in case the program is wiped (eg, he forgets his password). A random ID in the installer would kill my chances of that...

The program is going to be installed on my client's laptop and the only way anyone (read law enforcement) would get hold of it would be to confiscate the laptop. That's why the program wiping idea. If I had to crack a program, the first thing I would try is a dictionary attack. In my program, that leads to the program being wiped (not deleted, wiped).


Cheers,
cgkanchi

So wait, the encrypted data is stored in the program and then the program is password protected with that password stored in two places in the registry? Is this correct?

Not exactly.
1. The encrypted data is stored in a file outside the program.
2. The key to decrypt the data is stored inside the program.
3. The password itself is never stored anywhere. Instead a hash to the password is stored. By the very definition of a hash, the password cannot be recovered from the hash. The only way to check if the password is correct is to hash the entered password and compare the hashes.

====================================================================

Another idea. Why not make the plaintext password a (variable) part of the key so that the key is only useful as long as the entered password is right. Once the program wipes itself, the hashes are gone, therefore even if the installer is found and the program is reinstalled, without the right password, the data cannot be decrypted.

Cheers,
cgkanchi