As with alarms, there are different grades of signalling devices. These go from grade 1 (low risk, doesn’t seem to be used much or at all) to grade 4 (high risk, banks, jewellers). It’s common for the signalling device to be a higher grade than the alarm system, although this is not mandated.
Grade 4 requires encryption, protection from message substitution and replay etc. One provider, WebWayOne has built a system that uses several proven technologies like AES-128 and other widely known cryptographic fundamentals.
One of WebWayOne’s representatives said on the forum:
“Once these techniques are in place they may as well be deployed across all grades if system, it makes no sense not to.”
This is an awesome attitude to have and, to me, signals that these guys have actually understood the challenges in implementing a secure protocol. They are not weakening lower grade systems by weakening the cryptography and protocol.
Why do I think this is sound reasoning? It’s probably easier to argue why weakening the cryptography and protocol is not a good idea – here are some ways I have seen it done in other systems using cryptography (not alarm signalling systems – I am extending my reasoning from other products to apply to them).
Some products differentiate different grades of security by reducing key length. This tends to be a bad idea.
Practically all cryptographic techniques are vulnerable to brute-force attacks – it really is just trying every single key, one by one. It’s accepted at the moment that 40, 56 and 64 bit keys are not long enough to protect against brute-force attacks. 112 bit (twice 56, used in keying method 2 in triple DES) and 128 bit are currently long enough to protect against brute-force attacks. This will change in the future, but we are safe for a good few years yet.
Anything above 128 bits is therefore deemed wasteful – your highest grade product could use 128 bits and be secure. You could alter your lower grade product to use 64 bit keys. To the lay person, you might think that this would take half the time to brute force – but it is actually easier by a factor of 2^64 (18446744073709551616 times easier).
You could offer 127 bit encryption – this would take half the time to crack. But what would be the point? It would be product differentiation for no reason, and implementing a custom key length nearly always means you are “rolling your own” and will make mistakes.
Altering the protocol
Changing the protocol in anyway would also be an odd way to differentiate a lower grade.
Outside of key length, most aspects of a protocol are either a binary secure/not secure. You can’t offer 50% of message authentication. You can’t offer 50% of a secure means of key exchange. They are either present and secure, present and insecure, or not present at all.
If any aspect of a secure protocol is deemed insecure, it’s highly likely that the whole thing will fall apart. This isn’t always the case, but it’s fairly usual to see a theoretical vulnerability against a single part (say, the message authentication) turn into a full blown practical exploit against the whole thing. This means you need to tread carefully when trying to artificially weaken a protocol.
The hardware is there anyway
Signaling systems don’t have the same constraints as wireless detectors. They have plentiful power and space, which affords the use of comparatively powerful hardware.
Most detectors use 8-bit microcontrollers like the PIC, ATmega, or 8051 built into the CC1110. They run using slow clock rates (this lowers power consumption) and have limited RAM and register space. Implementing full blown cryptographic schemes in these is not easy, especially when you move up to something like RSA with 1024 bit keys (RSA is public key cryptography, where you need a much longer key to be secure than with symmetric cryptography like AES).
I have not seen inside any IP signaling devices, but I would wager that they use modern, powerful 32-bit processors like the ARM, with plentiful RAM and fast clocks. There are cryptographic libraries already available on these processors that allow you to easily build a secure protocol.
This hardware is likely the same across all grades. Again, it just makes no sense to build a lower grade system using different hardware to artificially constrain it.
Properly pen testing products, as compared to “test house” testing to standards, is a time consuming, expensive and highly skilled job. Having two distinct products, even if they only different slightly in hardware and software, would really require two distinct pen tests to be performed. This is cost you do not need to bear. Test the grade 4 product, use the same hardware and software for grade 2, and you have just tested both at the same time.
Differentiate on the tangible aspects
When it comes down to it, all of this doesn’t really matter to the customer. They just want something secure. So differentiate on the tangible things – how long the signalling takes to report issues, and the response to alarms.