My thoughts about Cryptographic Camouflage / Software Smart Cards

Post date: Jan 19, 2014 1:43:56 PM

Studied whole white paper of Cryptographic Camouflage by CA.

"From: Proceedings of the 1999 IEEE Symposium on Security and Privacy. Copyright © 1999 by The Institute of Electrical and Electronic Engineers, Inc. All rights reserved. Software Smart Cards via Cryptographic Camouflage"

Here's my reply, because original message which I replied to is in closed forum, I'm unfortunately unable to quote it.

I liked that cryptographic camouflage. I hope I'm not breaking your patent when I'm storing my own passwords temporarily on some medium which I don't perfectly trust.

What I do? I'll take my password and encrypt using some quite simple method and chosen password? What that isn't secure, anyone can crack it. No they can't, if my password would be originally plain text, it would be easy to take original_password and XOR it with temp_password. But because now the original_password is totally random, even xoring it with short temp_password in ECB mode is enough. Because decryption with any key, result is still random, and there's no way to know when you have correctly decrypted the password. Of course I use something else than XOR because binary operations aren't handy on paper, but Vigenère cipher is easy to use, and you can add layers of transposition, fractionationing or chaffing and winnowing. These methods are all usable on paper, and algorithms are easy to memorize. Just if you want to make it extra secure. So, my final question is if password FBVOctJwPYlU correctly decoded or not? ;)

This is just exactly the same methodology you're using with crypto camouflage to hide keys. It's nice that someone granted a patent for such a simple trick. Basically everything that is required, is encoding data so that it's information density grows to a such level, that all bits do matter, and basically causes any result to be valid.

Btw. I wrote this before reading the paper. Now I'll read it. And let's see how close I got to the implementation.

Hmm, paper looks good, until 2.2. Where they say "Conceal the public key and don't use it to encrypt verifiable plaintext", this could be a major problem.' So basically all messages encrypted should be cryptographically random binary nonces and public key needs to kept hidden.

2.4. Was quite iffy too, but basic point is that if the device is already compromised on software level, they can get the key.

With TEE they directly can't do that, but they still can probably scam the user to sign falsified information and signature request, because application software controls the device display.

Generally that's nice way to store PKI keys securely on device, so that having the device / it's data storage won't reveal the private key and doesn't require too high encryption key entropy (aka too long key to be typed in).

But isn't that just bit over complicated? Because using the method which I mentioned above. You could basically do the same. I have a random (symmetric) private key which is encrypted with my PIN. Then challenge nonce is hashed with this private key. Result is same, and the output response to challenge is random and wrong, if the PIN wasn't correct. Only way to know if it was wrong, is to submit it to the server which sent the challenge and see what the end result is. This is a simple method which is used with countless different service REST APIs etc. Only drawback of this much simpler approach is that the server has to know the key for verification purposes, because it's symmetric signature scheme.

Both of these methods are completely non-secure, if mobile device has been compromised on OS level. They can steal the key, when it's unencrypted or they can steal the key and PIN when key is being accessed.

- Thank you. It was a good read and a little brain teaser. It was what I expected it to be, and there was a good analysis of different attack vectors.