how to Add encryption facilities to the configuration file functions

[yiweihua2002]

       We want use configuraion file store Constant,and we want only the man who has privileges can modify the Configuration file,my question is: Are there some method use LabVIEW to add a secret to the configuration file?I had seen A software engineering approach to LabVIEW by Jon Conway, Steve Watts,this book had told me one method to add encryption facilities to the configuration file functions,but I do not understand how to do it.

[mikeporter]

Are you wanting to restrict access to changing the setup values or restrict the ability to view the setups? There are VIs for doing Blowfish encryption. The result is a string of ASCII characters that can be stored in an ini file. Storing setup data in a database can provide finer-grain control over permissions.

Mike...

[yiweihua2002]

Thank you mikeporter ,through your answer,I have some Ideas,I want to restrict access to changing the setup values,and I am afraid to that someone can directly use windows Notepad to modify the INI File.

[mikeporter]

Well you could use the blowfish VI to encrypt the data before it is written to the ini file and decrypt it when reading.

Mike...

[yiweihua2002]

I know how to do it,Thank you very much!

[rolfk]

---

@yiweihua2002 wrote:

Thank you mikeporter ,through your answer,I have some Ideas,I want to restrict access to changing the setup values,and I am afraid to that someone can directly use windows Notepad to modify the INI File.

---

I did something like this and what I did was basically extend the Config Close file to calculate an MD5 hash over all keynames and keyvalues of a given section. When the config file is written the calculated hash is added to the section as an extra key and on reading it is compared with the stored key and an error is returned if that doesn't match. Obviously there is a special administrator mode in the application which skips the comparison on ini reads so that a "corrupted" ini file can be restored by a privileged user.

Rolf Kalbermatter

[danny_t]

Hi,

Just to add another option for anyone reading this post, we are using The GNU privacy guard (GnuPG) from http://www.gnupg.org/   (http://www.glump.net/dokuwiki/gpg/gpg_intro for a ggod user guide intro) to sign all our limits files.

We keep our test set limit files in excel spreadsheets this gives us a nice readable format, we then have a macro that using the GnuPG and a private key, to generate signed limits text files.

All the test station have a copy of the matching public key and in LabVIEW we check the limit file sign to see if they have been tampered with in any way. Only people with the passpharase and a copy of the private key can run the macro to generate the limit files.

I think this has an advantage over MD5 method as without the correct private key and passphrase you cannot generate a correct sign that will be validated with the public key, so you are guaranteeing who created the file. I think in the MD5 situation,  there is nothing to stop sombody editing the file and putting their own new MD5 calulated hash in place so you would never know the file had been played with,  the MD5 will deal with  corrupted files or half hearted tampering fine.


Into from the GnuPG web page..
============================================

The GNU Privacy Guard

GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC2440 . GnuPG allows to encrypt and sign your data and communication, features a versatile key managment system as well as access modules for all kind of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also also provides support for S/MIME.

GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License .

=============

regards

Dannyt