Hi,
As system integrator, there are some cases that I like to protect my resources in ignition after delivering project to client.
For example creating a library that use resources like python lib and views,…
In other SCADA packages I can put password and encrypted the resource. The resource can be used by system but can’t modify by others unless they know password.
The protect option in ignition doesn’t work because when other can access to gateway config they can change the role and password so it’s totally pointless.
Even gwcmd -p command can reset password.
So what is the available method to deal with these scenarios?
Of course creating module is one option but it’s really hard. I hope we have option to simply encrypted resources in ignition.
Thanks for any ideas.
OEM lock in previous versions used to provide some amount of obscurity but it’s no longer available in 8.0+.
We don’t really have a replacement in the works right now.
The truth is there is no way to actually secure your resources. If Ignition can read them, which it must be able to in order to function, then so can any moderately determined or intelligent adversary who has access to your gateway (local filesystem access, not necessarily remote, though it can also be achieved by someone with Designer access). There is simply no way real, secure, way around that. There are options that would obscure or make it more difficult but nothing more.
This begs the question of who actually owns that resource once it's delivered.
All of my companies PO’s to OEM’s include a clause which states that we own rights to all programming, and that it may not be locked, protected, or encrypted, for this very reason.
I’ve worked on both sides of the table and understand the reasoning behind wanting to protect your work. I’ve also been frustrated more than a few times when I needed to understand why something was not working as expected but couldn’t because the code was locked.
My reason is the same as when people create module for ignition and add license to it.
The difference is for library in a project is not economic to make modules.
I wonder why ignition can’t encrypt resources. Is it that hard?
And if it is wrong why other SCADA solutions has this option?
As Kevin pointed out, If Ignition can read it to use it, the decryption key must be part of the Ignition install and can be used maliciously to bypass the protection. The text-based resource model adds to the difficulty.
They have the same vulnerability. It is of marketing value only. Such techniques are speed bumps for determined intellectual property thieves.
Learn enough java to re-implement your scripts in a custom, licensed module.
A similar consideration is that a lot of clients require access to change alarms and customise reports, but giving them this also means providing access to all screens, etc. It would be nice to be able to expose these without full designer access.
Not to mention, some other scadas you compile the project which is basically the best reverse engineering protection you can get, but also makes it more painful to deploy
Your fear seems to be that you will deliver content to a client and that client will steal your content and use in ways that they don't have the rights for.
However any sufficiently motivated individual can extract data from a running system because the system itself needs direct access to that same data in order to run. And there will always be individuals who see a locked system as a challenge to be conquored.
They key point then is "sufficiently motivated".
By providing a quality service and product to a client and being a responsive supplier you will definitely lower their motivation to steal your secrets. (And I would argue that most clients are not even in a position to make use of your technical resources outside of the systems you deliver - otherwise they would already have the skills to create the equivalent of your work in-house.)
So what can you do? Nothing much technically really. But that leaves open a legal approach where by your contract with the customer clearly states the rights of the client that you are licensing your technology to. Then when a client steps outside of those rights you can seek a legal penalty. (However that also requires you to have the available legal resources to write a solid contract, and the ability to detect when something happens) .
@pturmel suggestion of learning Java and building a custom module does raise the amount of motivation that someone will need to have in order to steal your secrets. However if I was sufficiently motivated then I would deploy a custom JVM that allowed me to see the internals of what was going on. (But I admit that would take a lot of effort to actually understand what I was seeing - and would require me to have a very well developed programming skillset).
In general you can't protect your secrets from being seen and while an honest client will not steal them, a dishonest one will regardless of the protections. But there are legal options for protecting your rights when dealing with any client.
Finally your question is not a new one and has been asked over and over on various software forums. Here is a version from 10 years ago: How do you prevent the piracy of your software?
If you want people to pay money for your product, copy protection is not the answer. It never has worked and never will. The answer lies in Economics 101: people will pay money for your product if they perceive its value to them as being greater than the price you are asking for it. Otherwise, they won't. Period.
Don't have to work even that hard. Decompiling java is almost trivial. But a custom java module is the most secure of the IP protections available in the Ignition world.
Bingo! That is the key, particularly when dealing with non-technical purchasing people. Provide generous rights to clients to enable them to maintain the systems they paid you for, even if you aren't available yourself. Not necessarily ownership of the IP (I greatly resist handing over outright ownership of the IP I create).
Yes, one must learn how contracts work, and learn enough about copyright law to provide input to your own legal counsel.
People make modules to enhance functionality and make it available to the public in the interest of generating revenue via licensing, irrelevant of the project.
Why would you want to encrypt/protect/lock a project resource that has no value outside of a project?
I don't hire OEM's because I can't do the work, but because I don't have the time. Admittedly, I'm probably a rare breed.
He says as he posts to a forum in the middle of the work day. 
Clients won’t steal stuff - that competitor of yours they used on that very similar last job will when your client has a great idea to get them in for a cheap audit on your contractual compliance.
He says as he posts to a forum in the middle of the work day
If we didn't spend time amassing knowledge we wouldn't be in the position we are 
No harm in a bit of employer-subsidized education
Hmm I live in Mountain time and work in East Coast time, so am I posting in the middle of the day or in the hours before work? 
Now if you'l excuse me, I have a cat to let out of a box
Of course if resources and liberty can be used out of the project. Some times the technique you use is enough for your competitor.
It is specially true for OEM and repetitive and similar projects.
And I want that encryption, because I don’t have knowledge and time to create modules in java.
Even encryption of resource is not 100% guarantee it but it is better than nothing for most cases.
And one more thing, right now there is option to right click and protect resource in ignition.
What is phylosiphy of that?
what is the benefit of it other user can simply open resource?
Why ignition in the first place create it if protection of resource is not important?
It's an indicator to another friendly developer, not protection from an adversary.
It is simply for protection against accidental changes.
If you have a business need for intellectual property protection in Ignition, you have a business need to learn java and learn to write modules. Whining about the deletion of a pseudo-protection feature that IA determined they could not make work effectively is not advancing your business case.
Wouldn’t having different permissions on different parts of the designer be a relatively cheap way to solve Nader’s problem? You could give your client access to all of the areas other than, say, scripting and retain the admin credentials and the server credentials. It would then work if your concern wasn’t scripting but some other part of the system like blocking your competitors from copy+pasting all of your perspective components and getting an easy leg up or some clever API you built in webdev.
(Disclaimer: doing that might be way more difficult than I’m giving it credit for)
It is.