Secure File Data

[kroyaras]

So I am trying to make a read only format of results data. Currently the test data is saved as a text file but I want to prevent users from modifying the file. I am running into an issue where I can seem to create and save the data file so it is unmodifiable. I've messed around with the set file permissions vi but keep running into not being able to save the data.

[RTSLVU]

Well you know there is really nothing you can do short of either encrypting the text or storing it in a binary or some proprietary format that is not easily readable without the right "reader" program. 

Anyone can change file permissions on a Windows system so making it read only does nothing except keep honest people honest.

What's to stop anyone from opening the data file in another program like Notepad++ and changing the data?

But in general you need to do this:

When you open a file use the low level Open File primitives that outputs a file reference, not a file path

Pass that file reference through your program and use Write Text to File for writing

Remember to close the file before AND set it read only before you exit your program

Doing it this way your data file that you are writing to will be opened as Read Only and Windows will lock the file access so no other program can open it while LV has it open.

[kroyaras]

That's my biggest problem. For the most part the users of the computer don't access the txt file to see the data. Theres a built in "display results" function. I've gone through thinking maybe making the results directory hidden. I've tried to write the data to a binary file in labview but the text stays the same. This "securing the files" thing has come from the top down so I'm stuck scratching my head trying to make it locked down but just end up in the same position of theres really no good solution.

[RTSLVU]

This is a tough one....  Simple encryption and a "converter program" would be where I would probably go

But using the Excel toolkit you can write your data directly to Excel files.

I know in Excel you can digitally sign and mark a file as final. Now anyone can still change the file BUT they get a warning that the file has been marked "Final" and changing any data will remove that. Or if they use another program  ithe file will fail the security check next time is is opened in Excel (Everyone will know it has been altered) They will have to sign it to mark it final so you will know who changed it.

That being said I do not know if the Excel tools in LabVIEW can digitally sign and mark a file as final.

[RTSLVU]

Here's a simple file encrypt/decrypt I wrong a long time ago maybe you can modify this to work "on the fly" in your program.

https://forums.ni.com/t5/LabVIEW/Encryption-using-Fast-Fourier-Transform/m-p/3795222/highlight/true#...

[Kevin_Price]

[Edit: after posting, I see that a couple partly similar suggestions came in while I was composing this.  End edit.]

Just to add another thought to the mix...

We had similar concerns about certain input and configuration files.  We wanted to support the ability to edit configurations, but also the ability to distinguish between a validated config and an experimental one.  We settled in on a scheme of *authentication*, based on a crypto-hash of validated configs.

Alone, this does nothing to *prevent* edits and changes, but it does *detect* them very effectively.  Adding something like this to your current efforts might (?) help satisfy the requirements coming from the top.  Read-only is like the protective fence around the data, preventing honest and inadvertent edits.  An authentication scheme is like the alarm system that knows whether the fence has been bypassed.  It doesn't make the fence more secure, but it *can* inform you whether or not the *data* is secure/unchanged.

-Kevin P

[cstorey]

There are a bunch of LabVIEW Encryption implementations you could use...(more if you search the forums)

- https://github.com/IgorTitov/LabVIEW-Advanced-Encryption-Standard

- http://lavag.org/files/file/198-encryption/

You could just store the hash key in the program which could be either compiled or password protected.

You could also save the file with a unique file extension (*.1up), I know that is enough to confuse some of my users!  

[altenbach]

Maybe you can burn the data to a plain old CD-R and distribute that. The only way to modify the data is to shred the disk. 😉

[crossrulz]

My "poor man's encryption" is to simply invert all of the bytes before writing to the file (String To Byte Array, NOT, Write To Binary File with the "Prepend Array Size" set to FALSE).  It is far from secure, but it does apply enough to keep the curious at bay.

My next thought would be to use a SQLite file format.

[thols]

If you use "Write to Binary File" but don't input the string but the numeric data, then the result is a binary file that is not easily interpreted or modified. You could also write the data but encase it in a cluster together with some other useful or random data if you want to stop the average LabVIEW-programmers from reverse-engineering.

If that is not enough, encryption and signing has been suggested. You could also do an MD5-hash of the file to detect tampering. There is an MD5 VI in LabVIEW.

It is also apparently possible to sign xml-files.and possibly any file contained within that file. I just saw it so I'm not sure how that works though.