So you’ve decided to secure your control network. But how much security do you need? The most obvious answer is, “As much as I can get.” But control networks are not always point-to-point. Sometimes you want a “door open” message to go two places; like to both a door controller and a lighting system. Do you really want to share your security system encryption key with the lighting ballast?
While having data encrypted can be important, it is not always necessary, and it can lead to systems that become closed to interoperability. Encryption is useful for document content and credit numbers: things that are useful out of the context of the media in which they travel. If a credit card number with expiration date is found on a piece of paper on a desk, it has inherent value out of context. It can be used to make a purchase (see illustration).
However, finding the word “Paris” on a piece of paper means nothing if it is out of context. Only in context can it have value: “City of Birth,” for example. When calling your bank to find your account balance, you need to verify that you are really the person named on the account. They have information that only you should be able to answer: “Shemp” “1234” – information that means nothing out of context: first dog = Shemp; account PIN = 1234.
These types of data are only valuable to determine the validity of the person making the transaction. For this, authentication is important.
Authentication is useful for defining originator or requestor: things that have no meaning out of the context of the media in which they travel. Is it important that a signal from the security system of a building to a door controller be encrypted so that it cannot be read?
If the signal is to a door controller, anyone can guess that it is to either open/unlock or close/lock the doors. Therefore, encryption is not very helpful in this case – and it prevents the lighting ballast from understanding the message.
It is more important that the signal from the security system to the door be authenticated so that it is verified to come from the correct origin. Being a readable message, it can also be shared with the lighting system.
For control networks, authenticated messages can prove to be more valuable than encrypted messages. Though encryption can be used in the authentication proc-ess, the message is not encrypted. The following is a Security/Door example. There are other authentication methods, but this is the one used in LonWorks networks – a common protocol used in many building systems:
Security System: [“Open Door” message]. The Security System makes a request of the Door Controller.
Door: [Challenge Message to Security System]. A random number is sent back. That same number is used to compute a transformation using the encryption algorithm, authentication key, and the content of the “Open Door” message. The transformation is stored for later.
Security System [Challenge Reply to Door]. The random number received is used to compute the transformation using the same encryption algorithm, authentication key, and content of its original “Open Door” message. This transformation is sent back to the Door.
Door: [Acknowledgement to Security System]. The Door Controller compares the incoming transformation to the one it stored for later. If there is a match, it takes action as programmed (it opens the door), and it replies to the Security System with an acknowledgement.
Jeremy Roberts is the principal engineer of LonMark® International (www.lonmark.org), Jamison, PA, a non-profit organization dedicated to the promotion of LonWorks® networks based on the ANSI/EIA/CEA-709.1 Control Network Protocol.