Password Protecting VIs is Security Through Obscurity

[Jim_Kring]

I'm sorry to be the one to break the news (but, I'm sure I'm not the first to say this):

• Password Protecting VIs is Security Through Obscurity

[Henrik_Volkers]

---

@Jim Kring wrote:
I'm sorry to be the one to break the news (but, I'm sure I'm not the first to say this):

• Password Protecting VIs is Security Through Obscurity

---

Yepp, you are right

http://forums.ni.com/ni/board/message?board.id=170&message.id=192756&query.id=395047#M192756

that thread is more than one year old, I still wonder there is no unlocking tool somewhere in the net.  I expect that all it needs is just a 'patch' of the regular LV to skip or inverse the result of the password validation because the diagram not even seems to be encrypted.

Message Edited by Henrik Volkers on 08-20-2007 02:57 PM

[shoneill]

Disregarding the fact that password protection is inherently protection through obscurity (if someone knows your password, then you've lost protection....) I agree with Jim.

With scripting possible (I've never delved into it myself), there is probably only little missing before it would be possible to circumvent the "password protection" of LV VIs.

On a side note, what so we suggest as an alternative? Encryption with password protection?

Shane.

Message Edited by shoneill on 08-20-2007 03:02 PM

[Jim_Kring]

---

@Henrik Volkers wrote:

Yepp, you are right

http://forums.ni.com/ni/board/message?board.id=170&message.id=192756&query.id=395047#M192756

that thread is more than one year old, I still wonder there is no unlocking tool somewhere in the net.  I expect that all it needs is just a 'patch' of the regular LV to skip or inverse the result of the password validation because the diagram not even seems to be encrypted.

---

Henrik,

Thanks for the link.  I suspect that people have cracked the LabVIEW password scheme but are simply not telling anyone.  IMO, this is a very dangerous scenario.

-Jim

[Jim_Kring]

---

@shoneill wrote:

On a side note, what so we suggest as an alternative? Encryption with password protection?

---

Shane,

Encryption is only one more degree of obscurity, since LabVIEW must still have the ability to programmatically unlock the VI's block diagram.

I have mentioned some possible solutions on my blog posting, such as platform-independent byte code, but this is non-trivial and has performance considerations.

-Jim

[shoneill]

Jim,

I guess the part about your suggesions which I didn't get first time round was that you are, I presume, suggesting the changes in order to allow us to simply save the code without a block diagram while maintianing cross-platformity (!?) and so on, thus removing the neccessity at all for a password.  This didn't "click" the first time I read the blog (I did read before I posted). My bad since your text "So, what can NI do to devise a better scheme to lessen the need for distributing password protected VIs?" should have hit me with the clue bat!

Is there really a practical solution to the problem?  Would encrypting the block diagram add a sufficient barrier to prying eyes

Shane.

[Jim_Kring]

---

@shoneill wrote:

Is there really a practical solution to the problem?  Would encrypting the block diagram add a sufficient barrier to prying eyes

---

The only immediate outcome that I see, is for NI to be very explicit that password protection is not an assurance that your block diagrams are secure.

[Enrique]

As far as I know (and I don't know that much about development environment), LabVIEW is (one of) the only development environments that provides a mean to "protect" actual code. As I understand it (and this all in logic), you are actually working with LabVIEW to provide access to the code, because in this instance you can view LabVIEW as some sort of interpreters that knows how to render the VI code. Other than that, the code has always been there.

Others already has expressed their concern about the password protection mechanisms. Rolf K. has always trying to explain it as best as he understand it. GeorgeZou has gone as far to say something like that it is not real protection and that's why he distribute his VIs compiled. When you compile it, the code is there, but in machine form, which is really as far as you can go to "protect" executable code without going into esoteric solutions.

Once I mentioned that the VI protection relies on National Instruments reputation. That is an extension to the fact that they are not telling how the mechanism works - you have to trust them when they say "it works". I am not trying to defend National Instruments, but the fact that they are not telling does not imply "security by obscurity". It means it is unknown. "Security by obscurity" also means that once the mechanism is known, it is broken. If some day somebody publish how the VI protection works, and by having that information the mechanism is broken, then it is confirmed that it was indeed security by obscurity. But, the fact that they are not telling do raise suspicions. You just need the final evidence.

I always ask the question “what is that you are really protecting?” Surprisingly, most of the time is not the algorithm, it is the data that is processed, and it is not confidentiality the main concern – it is integrity. But customers usually does not understand that unless you educate them and ask the right questions.

Another question I ask is “from who? The competition? An employee?” It is important not to be paranoid about security. Secondly, when you heavily invest in information security (which is at the level we are talking) is because you already invested well in the other three areas above this, have you?

At this point it is pretty clear that that little VI protection mechanism is truly “false sense of security” if they really believed that’s all the security they needed, given that the code is really that sensitive.

So, I don’t dwell much about it. Most of the time is not even close to be a security solution.

[Jim_Kring]

Hi Enrique,

It's good to hear from a security expert (you, of course) 🙂

Thank for offering up your take on the matter.

Regards,

-Jim

[Jim_Kring]

And, here's an interesting comment on the article that shows the risk of relying on password protected VIs.