Protect ini file?

[george seifert]

Is there any way to protect a text file written using the Configuration File VIs? I didn't think I'd run into a problem using an unprotected/unencrypted file in the area I'm in, but I did. I have a bunch of routines in place for reading/writing these files so I'd rather not have to switch to a different type of file. The only thing I've come up with so far is to write the file like I usually do and then convert that file to some type of binary or XML format and then delete the text file. Then I'd reverse the process to do a read. Is there a more elegant way to do it?

George

[Phillip Brooks]

In "A Software Engineering Approach to LabVIEW", the authors have examples of writing wrapper functions to do exactly what you describe (Chapter 6).

You can find some of the code from the book here, but the latest version is LabVIEW 6.1.

[asbo]

Is your code being run by the same user who is mucking around? If not, both *nix and Windows will let you tweak read/write privileges on per-user and per-group basis.

[Shaun Hayward]

I would do one of two things depending on whether I simply needed to obscure the data, or properly protect it:

1. (simplest) Byte-Shift file

Once you have closed the config file, re-open it as a binary file, and add a known offset to each of the characters (convert the string to an array of U8's, add the offset and then convert it back to a string). This will make the file pretty much unreadable which should discourage people from messing around.

2. (most secure) Encrypt file

.NET comes with a whole bunch of cryptography functions which LabVIEW can call, making it possible to implement formal encryption methods without having to code them yourself from scratch (http://msdn.microsoft.com/en-us/library/system.security.cryptography.aspx). This method takes a bit of understanding of how .NET works and how to work with it in the LabVIEW environment (and also means that the application will be Windows-only) but results in properly secured data.

Which ever method I chose, I would probably write the data to a new, encrypted file, and then delete the original (or, if I was using the LabVIEW XML Schema functions, I would avoid writing the unprotected file in the first place and do the offsetting/encryption in memory before writing the file). I would probably also wrap al of this in a new VI called "Save Config Data.vi" or something so that the rest of the application does not need to worry about how the data is being written to file.

I hope this gives you some ideas.

Shaun

[crelf]

You can "protect" the data in any file by getting an md5 (or any like checksum routine) of it and then, when you go to read it again, recalculate the md5 and compare it with the original.

[Mark Yedinak]

You can also encrypt the file using the Blowfish algorithm. You can find the code here.

[george seifert]

Wow, lots of good ideas. Thanks. I was really thinking there weren't many options.

I think the only thing that won't work is to change the privileges. All users logon to this PC with a generic lab logon so there's no way to give rights to certain people. Unless maybe there's a way to protect the file from changes being made in Notepad or Word versus being written from LV.

George

[asbo]

I thought that might be the case, but decided to throw it out there anyway. There isn't a way to give permission per-process, so obfuscation/checksum/encryption is the way to go.

[Rolf Kalbermatter]

QUOTE (george seifert @ May 20 2009, 09:00 AM)

Is there any way to protect a text file written using the Configuration File VIs? I didn't think I'd run into a problem using an unprotected/unencrypted file in the area I'm in, but I did. I have a bunch of routines in place for reading/writing these files so I'd rather not have to switch to a different type of file. The only thing I've come up with so far is to write the file like I usually do and then convert that file to some type of binary or XML format and then delete the text file. Then I'd reverse the process to do a read. Is there a more elegant way to do it?

George

I solved such a problem by writing a wrapper around my Configuration File Close function. Basically what it does is to calculate an SHA128 hash over all the keys and key values in an INI file topic whenever the ini file is (rightfully updated) and adds this value as an extra key to that section. On opening the INI file I recalculate the hash and verify it to be still valid and otherwise post an according message and refuse to start the application in any other mode than the administrator mode which has its own password protected login and the adminstrator then has to go into the application configuration and verify all settings and save them back to the INI file which will update the hashes.

Of course not absolutely safe but for any practical means more than safe enough. With some extra documentation of the operation it would probably even pass most FDA requirements.

Rolf Kalbermatter