CBus network security

Hello,

I am currently working on the design of an automation system for a new facility my company is building. We are looking at integration between multiple system elements including lighting, burglar alarm and access control.

We like the CBus system and in particular the availability of the PAC, which is pretty much perfect for providing the embedded logic in our design. However, we are concerned about the security of the underlying cbus system and have a couple of questions that we would appreciate input on:

1) Is there any way for a device to ignore commands that originate from certain devices. i.e., only actuate if the input that changes a group status comes from a certain input device. (What we are concerned about here is having a situation where switching on a particular group will open a relay, for example, that will open a door through our access control system

2) If the situation described in 1. is not possible, is it possible in logic on the PAC to determine which input changed the status of a group? (I've not been able to find anything in the docs). In that way we could implement the application level firewalling we are looking for in code on the PAC and by using a serial controlled relay hanging off the PAC.

3) Is there anyway to protect against rogue devices being connected to the network?

Any help gratefully received.

Kind regards

Jon

 

All messages in C-Bus contain a header which includes the source unit address. If you built an application using a PC and a PC Interface, you could analyse the messages received by the PC Interface from units, and you could reject commands if they originated from units you wanted to ignore. This would of course require you to maintain a database of units, which would have to be kept up-to-date.

None of this is impossible, but I would have to take NickD and Daniel's advice that the PAC doesn't allow access to the lower layer communication facilities required for such filtering. You would probably have to write your own code to do this.

If you wanted to detect "rogue devices" connected to the network, you can also achieve this through the use of a unit address "MMI". or "Status Report". This mechanism inherent in all C-Bus units allows detection of each occupied unit address on a network, and also can detect conflicts (where more than one unit has the same address). Toolkit uses this to 'unravel' networks. You would have to run some background scan at regular intervals to detect the unit conflicts. Of course, a unit connected for a short period of time could easily be missed if your scanning interval was too great, so it is not possible to achieve 100% detection this way.

C-Bus units have been developed to suit the application they are intended for, and as such, there are no such security features in (wired) units controlling lighting or HVAC; a network used for lighting or temperature control can only be considered secure if physical access to the units and the wiring can be prevented.

An application requiring a higher level of security could be catered for by inventing new messages specifically for the application. I can see no reason why this could not be achieved, but there's a bit of work in it.

 

Does this mean that if C-Bus lighting were installed as one network in say a hotel then there is no mechanism to stop one room occupant gaining access to the wiring behind their switch and being mischievous ?

I would have thought for the larger installs like Wembly stadium and some Olympic sites that I believe have used C-Bus this would be a fundamental concern.

Or maybe these are so large that a specific encryption can be included in firmware.

K

 

Hi guys - popped back in after a few years to see how the old gang is going. I am glad my browser remembered my user password.

With nearly a couple of decades of security and C-Bus experience I thought I would throw this in. As the boys mentioned C-Bus is not a secure system / protocol - not intended to be. If you are wiring C-Bus or any similar system to a security system you should leave the security system "in charge". If there was a situation where you wired a C-Bus relay across the "output" control of an access control door you have fundamentally circumvented the control of the security / access control. As you know security / access control systems have input, output devices, encrypted data on their bus and a control database of user, door, access groups, time zones etc. When a door is opened many if not all of these elements are involved. Wire something in parallel and all those elements may as well not be there.

Possibly look at your requirement from this angle. Your "lighting control" relay could be connected to an input of the security / access control. I do this to arm my security system. Importantly this input can only ever arm the system. Close / open the contacts as many times as you like and you will never get a disarm.

For access control the same sort of input can be used. The access system can open a door as a result of your input during low security times / operations, however may ignore it if the system is armed, in alarm or a certain time zone is active.

You mentioned this was a commercial situation ? ? or at least some level of integration, most decent commercial and higher end domestic grade systems can easily do this sort of thing...

PS... I trust all the old C-Bus gang is happy and well...

 

Thanks

Hello everyone,

Thanks for taking the time to consider the situation and giving your expert feedback - much appreciated.

We will refactor the design to give monitoring of the access and security elements into CBus only.

Kind regards

Jonathan