I have a selection of source files in my software that I encrypt with a password via the properties menu. It is part of my build process because I store them in version control unencrypted. Is there a way to automate this process? I’d love to write a windows program that runs through a list of files and encrypts them for me, but I’d need to know what Automation Studio is using as an algorithm and how it knows the password so it can still compile and view the contents.
Something doesn’t add up for me:
1-You have a project where, as often happens, some of the files are encrypted (for example libraries) and some of the files are not (task in logical view).
2-You want to write a program with another platform to automate the encryption procedure but so that Automation Studio (AS) can recognize the encryption, so you want to know the algorithm and password encapsulation method that AS operates with.
Did I understand correctly or did I miss something?
I am also a little confused because it sounds like you already store your files unencrypted and you don’t need the password to build the project. When do you password protect the files? Do you share this project with others via a different channel than what you use for version control?
There’s a good discussion on source file encryption in an earlier Community thread. In short, the source file protection feature in Automation Studio is more of an access control check/deterrent than true encryption. The fact that you’re able to build the project without needing to input the password proves that Automation Studio knows it without your input. I’m not sure how this is done, and I don’t expect anyone from B&R would post that publicly.
My recommendation would be to put the code you want to protect inside of libraries and then import those libraries into the project as compiled binaries. This does a better job of protecting the code wherever it ends up. You can then keep the libraries’ source code in a separate version control repository that you control more tightly than the rest of the project.
Access control is all the more we’re looking for. Our source ends up on customer machines along with AS so we can upgrade and debug remotely. We don’t want users to be editing or reading certain tasks, so we password protect them. If you have them encrypted, it makes change tracking pretty worthless. So we keep a version control branch of it unencrypted and then when we release to a customer’s machine, we encrypt those files. It would be nice to not have to tediously select all the files of interest every time.
I see, thank you for clarifying!
You could use the “Protect project source files” feature in the configuration properties (where you enable saving the source files on the target).
This will password protect the entire project rather than individual files, though I would guess this probably suffers the same security limitations as the other form of password protection.
I agree with @marcusbnr the actual file encryption from AS isn’t a real encryption as it store the password inside the encrypted file. With a bit of time it’s pretty easy to get back the source code of a encrypted file.
I’m really not too concerned about the security limitations. I had a suspicion that the password was stored in the header since it’s the same on all my files that use the same password. I could absolutely paste that onto my encrypted file without knowing BR’s secret password-- if I knew how the rest of the file was created. I’m not so motivated that I’m going to try to use my password to and knowledge of the unencrypted file contents to reverse engineer this.
My understanding from delving into this before was that the Automation Studio is based around the Electronic Codebook ECB mode of encryption and it may have used a key embedded in the file or a dual key encryption with one of the keys automatically calculatable by Automation Studio. Hence Automation Studio can decrypt easily/quickly decrypt the file as it’s building, but only decrypts the whole file.
I do recall you can select multiple files to encrypt/decrypt at the same time, so do you have them in the same folder so multi-selection would be easier.
Automation Studio might also ‘salt’ the encryption so you need to use your password with Automation Studio encryption decryption algorithm.
One option I would lean to would be embedded that more proprietary code into Function blocks and then only use the binary version of those libraries in the project. I’m sure you could use some clever Git hooks or scripting to use embedded libraries when not on your company devices.
Perhaps naively, I thought they would publish the algorithm and the security lies in the users keeping the passwords secret.
All of the data files in the system dump are stored with a B&R encryption so that you have to use Automation Studio to view them. Even the System Dump Viewer tool on GitHub is only able to parse the SystemDump.xml for all of its information.
I agree a better feature would be for B&R to use some more open algorithms to encrypt.
Let me start by saying that since I don’t know the type of machine tool or process system you and your company develop and the relative operating scenario, so I could be wrong, but from what you say it seems to me that the problem should be solved during the design phase.
I never download the source to the cpu (rebuild/build times tool long and unsafe code control);
I instead leave the project zip to the client if he wants to do diagnostics.
So from my point of view there are two different ways to operate to avoid unwanted sw changes:
- or the machine can be developed by putting all the code to be protected in libraries whose binaries are then removed;
- or distribute control between SCADA and PLC and consequently structure the control sw (e.g. a Finite State Machine). On a SCADA, platform access control and change tracking are significantly easier.
In this case the SCADA will not be MappView obviously!
In my personal experience, B&R and the Automation Studio platform are the least appropriate and secure product for remote code editing and/or remote code debugging.
I learned that file encryption/decryption functionality is removed in AS 6.5, so that puts an end to this line of thought. Thank you all for your advice.