Plugin file encryption

Plugins & Plugin Development General Plugin Discussion
#1

Hi, I’m working on an open source plugin for a thermostat, but there is one data file that I would like to have encrypted in such a way that its contents bear the least risk of being misused. I know that I can encrypt specific files when packaging my plugin, but once this plugin is installed, won’t this file be sitting on the Vera in unencrypted form? I don’t see much information about what it means to encrypt a plugin file. Does anyone here have knowledge or experience with this feature, and how I can keep this file’s contents used for only its intended purpose?

Thanks for any ideas,
watou

#2

I have not tried the encrypted files … I would be surprised if it actually worked!

But I assumed that APP.mios.com would encrypt the file and that their LUUP loader that already does compression, would handle the decryption. The files on the Vera File System should be encrypted and/or compressed. The files stored on the SVN server would NOT be encrypted.

That way MCV holds the Encryption and Decrpytion keys.

You could do this yourself. Encrypt with a private key. Save the file as a data file.
In your plugin you could decrypt with a public key and then load the blob manually into LUA memory.
But then folks would be able to see your public key and grab your blob and decrypt it themselves.

#3

Thanks Richard.

[quote=“RichardTSchaefer, post:2, topic:174378”]You could do this yourself. Encrypt with a private key. Save the file as a data file.
In your plugin you could decrypt with a public key and then load the blob manually into LUA memory.
But then folks would be able to see your public key and grab your blob and decrypt it themselves.[/quote]

This is the situation I want to avoid, where once the plugin is installed, the file is either sitting unencrypted on the Vera or it can be easily decrypted. At the minimum I want it to be extremely difficult to obtain the contents of the file, but ideally, impossible. I suppose I will have to experiment, but it would be better if someone from MCV could explain what happens with encrypted plugin files.

If I find out more elsewhere, I will add it here.

#4

Just specify to encrypt one or more of your files and create a version.
You do not have to publish the version.
You should be able to upload the version in see if this works.
I have not been motivated to look at this.
I have not felt that any of my work was proprietary so far.

#5

On disk, it’s supposed to be encrypted… at least for the code files. This is why they have to “override” Lua’s [tt]require[/tt], so that they can write a filter that decrypts the data as they bring it into memory.

There is a loophole though, and that’s verbose-mode logging. There’s likely another if you can “strings” the [tt]LuaUPnP[/tt] process and work out the key.

For example, ERGY is “encrypted” using the model, but if you enable Verbose logging it dumps the first “n” lines of the [decrypted] source code for that file. In the day, this was well-enough for me to work out how badly ERGY was handling sensitive user-data.

So the encryption is a partial implementation at best… I don’t believe it’s changed since UI5 was released over 1yr ago, but anything is possible.

IIRC correctly, it’s another settings, in apps.mios.com, that also isn’t “remembered” like file location, so there’s a chance that you’ll forget to set it on one of the releases.

One of the many reasons I’m slowly pulling my plugins from apps.mios.com. I’d rather have manual installs than this buggy mess. 8)

#6

[quote=“RichardTSchaefer, post:4, topic:174378”]Just specify to encrypt one or more of your files and create a version.
You do not have to publish the version.
You should be able to upload the version in see if this works.
I have not been motivated to look at this.
I have not felt that any of my work was proprietary so far.[/quote]

Thanks; I will try this.

I am not looking to encrypt any of the source, but instead to comply with a vendor requirement about programmatic access to their services. The source will be completely open, but in order to actually interact with the service, the vendor requires that each integration uses a unique key that they issue. So in order to prevent some completely different piece of code from using the key they issued me, I need to track down a good solution for just this bit.

#7

Thanks, guessed – that’s very informative. I will see if I can make a ridiculously large .lua file that gets [tt]require[/tt]d into memory, so that the first N characters verbosely logged don’t reveal the key I’m trying to obscure. I will try any approach that allows me to comply with the vendor’s requirement.

But all this makes me idly wonder how much more awesome the Vera would be if it had a really robust app deployment model…

#8

Yep,
I started an App Repository.
I have high level framework in place.
Google App server - Vera User, Developer, and Admin login facilities.
I have the inventory of apps done - Either as Push from Vera Plugin … or Pull from APP site.
Next is to work on matching inventory with potential upgrades.
And last (and easiest) is the actual install.
The inventory will provide statistics on device and plugin useage.
Then more work on Vera User View to find, rate, … plugins.
Then more work for Developer User to Create/Register their software version (Either Zip or Tar File)
The web site will convert a Zip to a Tar file for easier handling on Vera.

I thought about encryption … but figured I would need to get MCV to provide a service to encrypt a file. I do not want to have to do a loader … and then there is the trust issue.

At present I can not think of a way to do encryption better than MCV. Although MCV can do a much better job. Anything we do can be analyzed and hacked. You can also do a lot of hacking because you have physical access to Vera. But that’s beyond the scope of mode casual programmers.

#9

For this, you might be better off putting the key into a crypto’d Device (XML) file.

If you put it into the Lua file, then it’ll be easy to write another plugin that “[tt]requires[/tt]” the file, and then calls the function to get it’s value out… depending upon how the code is structured (etc).

In the Device file at least there’s no easy way to “load” it’s code, and you can push all the interesting logic into the .lua file anyhow, so that the Device file is a thin shell + the key.

… and yes, if there was some focus on stability & usability, it could be a great product… one that I could recommend to friends and family. I’ve seen it evolve over 4yrs now, and the primary focus seems to be on 100% Support for every oddball Z-Wave device and “the next great thing”.

The problems here go way beyond the Store.

The first two yrs made great progress, but it’s in a perpetual orbit state for the last 2yrs now and it’s not clear to me they’ll ever land it. :frowning:

#10

That’s great, Richard! I can’t wait to try it, from both the user and developer perspectives. I hope it evolves into something that MCV migrates to and leaves the old system behind.

[quote=“guessed, post:9, topic:174378”]For this, you might be better off putting the key into a crypto’d Device (XML) file.

If you put it into the Lua file, then it’ll be easy to write another plugin that “[tt]requires[/tt]” the file, and then calls the function to get it’s value out… depending upon how the code is structured (etc).

In the Device file at least there’s no easy way to “load” it’s code, and you can push all the interesting logic into the .lua file anyhow, so that the Device file is a thin shell + the key.[/quote]

That’s a really good point – I want to, at a minimum, take away the “easy” tricks to gain access to the key, but also make all the rest of the plugin open source. It sounds like there is probably enough to work with here, but it’s not exactly straightforward…

[quote=“guessed, post:9, topic:174378”]… and yes, if there was some focus on stability & usability, it could be a great product… one that I could recommend to friends and family. I’ve seen it evolve over 4yrs now, and the primary focus seems to be on 100% Support for every oddball Z-Wave device and “the next great thing”.

The problems here go way beyond the Store.

The first two yrs made great progress, but it’s in a perpetual orbit state for the last 2yrs now and it’s not clear to me they’ll ever land it. :([/quote]

If MCV made as much of the Vera as open source as possible, and made clean lines between their licensed pieces and the rest, then I think the community could really dig in and give it a beautiful overhaul. A boy can dream…