MySecureDrive: Need user feedback

Hi,
I have developed a file-based encryption software which does transparent encryption / decryption to protect removable drives including CD/DVD. It also supports manual encryption / decryption of files / dirs using Drag & Drop. The software is called MySecureDrive, more info can be found in http://www.mysecuredrive.com. You can post any question in the MySecureDrive forum or this forum (if I have time to check).

The software is freeware but not open source. Please read the PDF user guide from MySecureDrive website. I can assure that there is no backdoor in the software. It is an exploratory project to find out whether general public like to use encryption product. Will appreciate any user feedback on bug or feature request.

Regards,
Sin-Lam

 

Hmm.

When I proceed to the site, all I see is a domain default page, as well as a 404 on the forum page. Could you elaborate on the threat model it's meant to address and the cryptographic primitives you've implemented to do so? Thanks!

 

LOL!!!!!!!!!!!!!

 

Re: Hmm.

The link is restored. Our ISP updated a web module last night and the website was reset.

The threat model is basically to protect file content when you lost (or someone steal) the removable drives, similar to TrueCrypt except it is file-based instead of container-based. It uses AES 256 bits encryption to encrypt files, which is derived from a password of your choice. Please go to the website to find out more information!

Thank you!

 

Use a MAC.

Okay, so using the AES with a 256-bit key is a good start; it can make 128-bit security a lot easier to achieve, given the fact that key material often leaks in real-world products. You say that the threat model is the lost or stolen removable drive; this is also similar to the threat model for Windows Vista's BitLocker.

However, as you might know, it's still possible for an adversary to manipulate the ciphertext. The lack of integrity preservation can also lead to a loss in confidentiality preservation. As such, you should always use a MAC when you can. If you apply a SUF-CMA MAC, such as CMAC-AES, to the ciphertext of an IND-CPA confidentiality mode of operation, such as CBC or CTR, you get IND-CCA2 /\ INT-CTXT security, which are the strongest notions of confidentiality and integrity. By the way, which mode of operation are you using?

With SecureFile, it seems that you have taken this into account, by using RSA to sign documents. On the other hand, I'm not sure why you didn't use a MAC here. By using CMAC-AES for authentication, you'd be recycling primitives, since you've already used the AES for encryption; this is good cryptographic engineering. Furthermore, by doing so in the Encrypt-then-Authenticate, or EtA, composition, you get IND-CCA2 /\ INT-CTXT security.

A MAC makes good sense, and even more so for MySecureDrive, which doesn't appear to have any integrity preservation at all. If you want confidentiality, you want integrity too.

 

Re: Use a MAC.

Thanks for your comments!
MySecureDrive is different from Full Disk Encryption. Full Disk Encryption encrypts every bit of data that goes on a disk. User cannot decide which file to be encrypted. MySecureDrive is a file-based encryption product, both plain and encrypted files can coexist in the same removable drive. And user can encrypt one set of files using one password and another set of files with a different password. MySecureDrive also allows stopping Transparent Encryption Mode, but still allow Manual Encryption Mode.

Integrity checking for plain text and cipher text are not supported in MySecureDrive due to performance reason --this is the same for Full Disk Encryption (BitLocker) and Volume based encryption (TrueCrypt). Adding a MAC for the whole data file or verifying it is not practical for updating a small part of a large file (e.g. database file update), or instant access to a large data file (e.g. viewing a video file).

You refer to SecureFile. It decrypts (decompress) and verify the entire file before the file can be used. This is good for manual encryption/decryption of documents and secure document transfer. It is however not good for interactive access and modification of large data files.

On the other hand, MySecureDrive does support integrity checking for its file header, including the encrypted random session key.

 

Hmm, need a little more clarification.

Right. I was simply referring to their threat models being similar, given that BitLocker has the lost or stolen laptop in mind and MySecureDrive has the lost or stolen removable drive in mind.

What is the primary difference between MySecureDrive and SecureFile? They both seem to work on files. As such, I thought it would be plausible to add a MAC. On a side note, while BitLocker doesn't use a MAC, because of it adding unacceptable overhead, it does do something called "poor man's authentication," which basically assumes that an adversary won't be able to manipulate the ciphertext in any meaningful way; in other words, any manipulation should cause the system to crash, before providing any useful service to the adversary.

To achieve this, they model their block cipher, AES-CBC + Elephant, as operating on large blocks of 512-8192 bytes, as opposed to LRW, which operates on blocks of 16 bytes. Their decision was one of data granularity and increasing the likelihood that any manipulation would result in a system crash, rather than anything useful. I can see a potential attack against LRW, because of the small block size, but I'm unaware of how this applies, if at all, to TrueCrypt. Of course, the attack could apply to a wide block, but with a decreased likelihood of success.

For this kind of thing, diffusion over a wide block seems to be the state of the art. Do you consider anything along the lines of data granularity? If you can't use a MAC, do you try to make meaningful manipulation harder for the adversary? There has been some interesting work recently, at UNC-Chapel Hill, in integrity preservation that, among other things, doesn't change the block size. You can check it out here and here. You might find it useful.

Okay. To preserve the integrity of a file, why not use a MAC? You could recycle the AES for this, and use a simple key separation technique to derive separate encryption and authentication keys from a shared secret. Is there any reason you use RSA instead? I suppose one reason would be if you wanted to send the file, but you can just as easily negotiate a MAC key.

How does this work?

 

Re: Hmm, need a little more clarification.

SecureFile is a PKI based manual file encryption & digital signing solution. It is a component of the SecureAge software and uses digital signature for integrity protection. Another component of the SecureAge software, called SecureDs, is more closely related to MySecureDrive. SecureDs is a PKI based on-the-fly file encryption solution that supports all storage systems (local, removable, network, CD/DVD, RDP, etc). There are also other data encryption components in the SecureAge software – as a complete package, it is an enterprise data security and encryption solution using the full power of PKI technology to facilitate key management and secure data sharing. On the other hand, MySecureDrive is a password based on-the-fly file encryption freeware that we hope will benefit end users who need a small, simple and standalone security solution.

Thank you very much for the references provided. Similar to other full disk encryption solutions, MySecureDrive uses tweakable block ciphers. And like TrueCrypt, MySecureDrive uses a variation of LRW. The BitLocker AES-CBC + Elephant diffuser you pointed out is very interesting and we would consider upgrading MySecureDrive in that direction in the future.

Note that MySecureDrive assigns a random session key to encrypt each file to prevent substitution (cut-and-paste) of data block from one encrypted file to another.

The usage of RSA in SecureFile is more than integrity protection as it also provides non-repudiation that is essential to business processes like work flow management.

MySecureDrive embeds an extra header to each data file. This is mainly to incorporate a random encryption key (CEK) to each file and to support secure sharing of documents by different users. It also includes other information like the actual file size and various security parameters for the file. A SHA-512 MAC is applied to the header to ensure its integrity.

 

Don't bet on it.

Thanks for shedding some light on your design choices, and you're certainly welcome for the references.

While non-repudiation sounds good in theory, it doesn't always look so good in practice. Seeing Alice's digital signature doesn't tell me that Alice signed it; it tells me that her private key signed it. This is a crucial distinction, because if there's one thing we're rather bad at, it's key management. To make matters worse, we're managing keys on systems that are difficult to secure, and it's plausible to assume that an adversary can get at the key and sign whatever he wants, to his malicious heart's content. As such, it would be a mistake to assume that real-world systems achieve the idealized notion of non-repudiation. PKI is risky business and can often make matters worse. To say the least: Be cautious.