Locking a ControlLogix

We tried for a long time to protect IP specific code while allowing the customer to still maintain access to general status. We used source protection but found an online program that had somehow obtained all the encryption keys for source protection. This was V28ish; I am not sure if it has changed now

I thought this was changed earlier, like 21 or so. From my understanding it's not encrypted anymore, but hashed. If you use a good password then there is no busting in.
 
I thought this was changed earlier, like 21 or so. From my understanding it's not encrypted anymore, but hashed. If you use a good password then there is no busting in.


This was was past V21; so I am not sure that is true. They might of been an even older method that was hacked as well.
 
This was was past V21; so I am not sure that is true. They might of been an even older method that was hacked as well.

I know using version 30 the online tool will not work. I think version 28 can still be cracked, but if it’s hashed it cannot be cracked with the online tool floating around.
 
Rockwell does have built in security now.

If you go in the "Security" tab in controller properties, you can actually end up setting it to a Factorytalk Administration server name.

If this option is enforced, PLCs can't be modified by any PCs which don't/haven't had have access to the server. The PCs don't have to be connected to the server at all times, the duration they can be offline can be changed.

Using the administration console on the server, you can limit what your users can do, and even link windows-logons(We have domain logons where I am) to the PLC privileges.

For example, maintenance can't do downloads on our PLCs, even by mistake. It's enforced from the server. Hopefully this helps, let me know if you have questions!

Hi,

Went into an offline file and selected the security tab but everything in there was greyed out.

Steve
 
Hi,

Is there a way to lock down a ControlLogix / CompactLogix processor to be read only i.e. only engineers for example can change the code etc. As I understand it, you can lock down a routine, AOI etc, either by source key or licence protection but there does not seem to be a way to simply lock down the whole processor for read only. Am I correct?

Look into FactoryTalk security and establishing user groups and permissions, possibly even linked to a Windows domain. This is one of a few good bridges to build with your IT department.

We tried for a long time to protect IP specific code while allowing the customer to still maintain access to general status. We used source protection but found an online program that had somehow obtained all the encryption keys for source protection. This was V28ish; I am not sure if it has changed now

Our outfit is rolling v32 code at the moment.

We've configured Logix source protection for code modules using a source key .dat file consisting of keys made of up to 40 characters per string (you can create more than one key within the file and associate code modules to unique ones, for example).

This is reasonably robust source protection.

One problem we had to solve on our own without shelling out tons of cash to Rockwell was execution protection (i.e. we don't want outside vendors freely deploying their own systems with our hard-fought modules). For this, we've embedded a source-protected hashing AOI within the protected AOIs we want to protect. A product key is passed from a public parameter on the controller to an in/out parameter of the protected AOI and then to an input parameter of the embedded hashing AOI. This AOI evaluates this product key against an internally generated one to maintain a license valid status. The product key is generated using a proprietary algorithm and attributes specific to the controller. Brute force attempts are discouraged with 15-second delays between false evaluations.

Some harder decisions come to bear with how to respond to an invalid license within the protected code.
 
Last edited:
This seems great for the end user, but not for OEMs and Integrators wanting to lock their stuff.

Hi,

Went into an offline file and selected the security tab but everything in there was greyed out.

Steve

In order to successfully do it, some pre-work is required.

You have to establish a common PC/server that all your programmers/maintenance/code-viewers have access to.

On this PC, search for the FactoryTalk Directory Configuration Wizard.

On the client PCs, Search for the "Specify Factorytalk Directory Location". Sepcify your common PC/Server on your client devices.

The grey box would then turn into a HOSTNAME for your common location.

Make sure your FactoryTalk Services Platform is up to date, or at least common on all PCs.
 
Look into FactoryTalk security and establishing user groups and permissions, possibly even linked to a Windows domain. This is one of a few good bridges to build with your IT department.



Our outfit is rolling v32 code at the moment.

We've configured Logix source protection for code modules using a source key .dat file consisting of keys made of up to 40 characters per string (you can create more than one key within the file and associate code modules to unique ones, for example).

This is reasonably robust source protection.

One problem we had to solve on our own without shelling out tons of cash to Rockwell was execution protection (i.e. we don't want outside vendors freely deploying their own systems with our hard-fought modules). For this, we've embedded a source-protected hashing AOI within the protected AOIs we want to protect. A product key is passed from a public parameter on the controller to an in/out parameter of the protected AOI and then to an input parameter of the embedded hashing AOI. This AOI evaluates this product key against an internally generated one to maintain a license valid status. The product key is generated using a proprietary algorithm and attributes specific to the controller. Brute force attempts are discouraged with 15-second delays between false evaluations.

Some harder decisions come to bear with how to respond to an invalid license within the protected code.


That's a similar method to how we approached it. How do you prevent the same PLC from doing something like "creating a duplicate line" within the same PLC? Do you generate unique keys per AOI instruction? How do you differentiate?
 
That's a similar method to how we approached it. How do you prevent the same PLC from doing something like "creating a duplicate line" within the same PLC? Do you generate unique keys per AOI instruction? How do you differentiate?

We don't limit instances per controller.
 

Similar Topics

Anyone else using Pi-Hole ? Had a spare Pi laying around a while ago and have been using this setup ever since. Browsing is not the same with out...
Replies
2
Views
863
Hello, Looking for anyone to help with a problem. We had a Panelview die with a power outage. Went to download the saved program onto a new...
Replies
9
Views
1,601
One of our Therm-O-Seal splicers has an issue and we are trying to access the PLC to help troubleshoot. The PLC is password locked and...
Replies
1
Views
1,294
Hi folks, I'm new here, but I'd been lurking for nearly a year... The company I work for is diving head long into a project with ControlLogix...
Replies
5
Views
2,187
Anyone run into FTME 11 just locking up when you do a right click then tag search/replace on a screen? Task manager can’t kill it and I must...
Replies
6
Views
1,517
Back
Top Bottom