Encryption Keys

[GregFreeman]

I was curious when you guys are encrypting files, where do you store the key? I have heard if you open a LV Binary in a hex editor you can relatively easily read string constants, so hardcoding in an encryption key may not be the best idea. In general, I am not worried about this happening as I don't need anything "super secure", but I wanted to get other's opinions/solutions.

[Mr Mike]

I was curious when you guys are encrypting files, where do you store the key? I have heard if you open a LV Binary in a hex editor you can relatively easily read string constants, so hardcoding in an encryption key may not be the best idea. In general, I am not worried about this happening as I don't need anything "super secure", but I wanted to get other's opinions/solutions.

 

I don't have an answer for you, but I just wanted to point out that string constants would be scrambled in a part of the VI.  It'd be hard to see the encryption key -- you'd need to know what part to get out, how to get that part, and how to unscramble it -- but it's not there in plain text.  If that's suitably secure for you, then go for it.  But I'd recommend against it

[ShaunR]

I was curious when you guys are encrypting files, where do you store the key? I have heard if you open a LV Binary in a hex editor you can relatively easily read string constants, so hardcoding in an encryption key may not be the best idea. In general, I am not worried about this happening as I don't need anything "super secure", but I wanted to get other's opinions/solutions.

 

It depends who you think your adversary is and what they will have access to. You should never "store" a key, rather let the user enter it - that is the only secure way. So when I'm encrypting a file, I never store the key (well, you could argue it is "stored" in memory, but that is transient and a whole subject in and of itself).

 

Many apps will store something in a file so that users don't have to keep entering the info. This should never be plain text, rather a hash of the password or the password with other stuff combined (SHA256 or SHA512 are quite common-don't use MD5), but this assumes the adversary will either not have access to that hash or will not be able to hook into the software where the key is used if they do get their hands on it. It's more of a case of "security through obscurity" than "secure".since whilst they may not be able to recover the original plain text directly, they may be able to inject the key, look it up on a public database or use it at some point in the applications process space. When used in this way, the key will usually be the result of not only the password, but the password combined with a salt. This, in essence is just another obscurity layer but means that two pieces of information are now required to reconstitute the original. It will, however, be for naught if they are both stored in the same place (a website, for example will store the hash in the DB, but the salt in a file).

 

Software is a tricky beast since if a competent  adversary has access to the machine, then all bets are off!.It's just a matter of time, persistence and budget.

[mje]

It depends who you think your adversary is and what they will have access to. You should never "store" a key, rather let the user enter it - that is the only secure way.

 

Agreed, though it's not inherently secure, rather it offloads the security to how the user handles the key. I'd say it's the most secure way software could handle it, but an uneducated or lazy user could still result in no better security than plain text.

 

So when I'm encrypting a file, I never store the key (well, you could argue it is "stored" in memory, but that is transient and a whole subject in and of itself).

 

Whole different subject indeed. Suffice it to say I would appreciate a "secure" data type where buffers are strictly managed and not copied at a whim. I shall not hold my breath...

[Tim_S]

I was curious when you guys are encrypting files, where do you store the key? I have heard if you open a LV Binary in a hex editor you can relatively easily read string constants, so hardcoding in an encryption key may not be the best idea. In general, I am not worried about this happening as I don't need anything "super secure", but I wanted to get other's opinions/solutions.

I put it in a single VI as a constant and wire that to an indicator (equivalent of a global).

 

It depends who you think your adversary is and what they will have access to. You should never "store" a key, rather let the user enter it - that is the only secure way. So when I'm encrypting a file, I never store the key (well, you could argue it is "stored" in memory, but that is transient and a whole subject in and of itself).

Software is a tricky beast since if a competent  adversary has access to the machine, then all bets are off!.It's just a matter of time, persistence and budget.

My adversary is the equivalent of "keeping out your little sister". I have user name, password and permissions for people who are generally honest people in the first place. I'm not working with government/corporate secrets or preventing people from destroying the world, so this works fine. I have more problems with operating system security where (the more benign) people want to go check out facebook or email and install games.

[ShaunR]

Agreed, though it's not inherently secure, rather it offloads the security to how the user handles the key. I'd say it's the most secure way software could handle it, but an uneducated or lazy user could still result in no better security than plain text.

 

Well. The ant-pedant in me ( ) would qualify that in respect to it is inherently secure at the application boundary. There is no software defence for a post-it note of the password on the monitor. 

 

 

Whole different subject indeed. Suffice it to say I would appreciate a "secure" data type where buffers are strictly managed and not copied at a whim. I shall not hold my breath...

 

Copying is not an issue, per se. It is the clearing of the memory locations and I don't know either way if LabVIEw does that. It is, however, swings and roundabouts since the key has to exist at some moment in time, in memory, so it is a case of reducing the persistence so that capturing at exactly the right moment on random off-chance is unlikely (not impossible, just unlikely). Of course. If there is zero cleanup, the keys can still exist for quite some time even after the application has terminated making them much easier to capture (until the OS decides it needs it for something else). So LabVIEW probably doesn't score well on that front. But more generally you get more bang for your buck by defending the edge (application/OS/network/buliding) and reducing the opportunities and attack vectors rather than trying to mitigate aspects that require enormous effort and skill levels to make the attack effective. Saying that. The SQLite API does clear all its keys immediately after use, but that's not a lot of consolation if LabVIEW holds on to the un-hashed password string like a drowning man to a buoy

 

Probably the best you could hope for is that LabVIEW clears its memory when it exits so then at least an attacker would have to have the software running after you have entered the password. However, if your secret data is so secret that you are worried about determined adversaries getting the keys from memory, it is better that they just don't get to run your software at all (lock the office door).

[infinitenothing]

You can add obfuscation (not real security). For example you could XOR your password with a second password.

[Rolf Kalbermatter]

You can add obfuscation (not real security). For example you could XOR your password with a second password.

 

And store that second password in the application! 

 

Granted it would maybe get the lazy adversary to think he got the password already and then give up if it doesn't work but it would be almost no win against any determined adversary.