Vulnerabilities In Ip Alarm Signalling Protocols

[cybergibbons]

I've made a quick blog post about this, because I think it is an interesting subject.

 

I can't seem to paste the content here without it looking ****

[james.wilson]

you could copy and paste it into a blog here?

[cybergibbons]

An interesting subject has come up on the tsi forums - product differentiation in relation to encryption and security in alarm IP signalling systems.

As with alarms, there are different grades of IP 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 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).

Reducing key-length

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.

Testing

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.

[james.wilson]

cb great post.

when i said blog here i meant

 

http://www.thesecurityinstaller.co.uk/community/blogs/

 

but still keep the posts coming. its good to see your view

[cybergibbons]

Yeah - I'll sort that out a bit later, was doing that post whilst you posted.

[Joe Harris]

Cracking information as usual CG - I will pose some questions to some of the other providers to see if we can summarise the current ATS encryption techniques.

 

The sad part of all of this is that the customer puts security far too low on their list.  If they were more educated and understood the potential impact then they might think differently.

[jimcarter]

Very good post.

There are some in our industry who do not think that encryption and substitution are important using the argument that there has never been a successful attack (implying there never will be), and maybe there hasn't been. Some will go along with this, but look at it another way.

First; never say never. This is the kind of attitude that the builders of the Titanic perpetrated.

Second, if you were successful in substitution (and ready to use that to your advantage) would you advertise the fact?

More importantly, no-one would know you had been successful (until it was to late!).

[Adi]

maybe yours but with hands like that id hate to see her snatch..

ha ha ha lol

[james.wilson]

Cracking information as usual CG - I will pose some questions to some of the other providers to see if we can summarise the current ATS encryption techniques.

 

The sad part of all of this is that the customer puts security far too low on their list.  If they were more educated and understood the potential impact then they might think differently.

i disagree joe sorry. Customers know less and care less than the pro's do. In their eyes all systems that get a nsi/ssiab cert are the same. Thats at a system level not a component level. I think the customer looks to the pro installer/maintainer to advise on the differences and as tsi alaone shows there is a bit of difference of opinion. The learning and understanding imo should be at our level not for the customer imo. We should advise to the best of our knowledge what is best for thier (customers) risk. Alas i dont think that is the case because a lot of installers dont worry about the question of the kit they choose from a security point of view. Most know whats defeatable kit wise, many know that 1 way rf is worse than 2 way. many many worries and most imo dont care cos 'ive had no issues with xyz' so its bound to be sound. When you look into it and understand properly how it works the fact usually that you havnt had an issue should be the start of the warning bells in your head. When you really look into it thats the time to really worry and check your insurance is up to date. Best way, fully understand the kit you sell and support then you can be confident that you wont need to claim on your insurance. Thats my position anyway

[Joe Harris]

I understand what you are saying JW - My argument though was for example a situation where an end user says 'why have you chosen Acme ATS when it is dearer than XYZ from this other installer?'

 

Of course the installer should be making a sound and informed decision, but with informed users seeking multiple quotes we are sometimes in a position of needing to defend the reasoning of one ATS over another when to a client as you rightly say - they are all the same as long as they meet the grade.

 

Coming back to CGs point, it shouldn't be a selling point of one grade over another.  That said - it should rightfully be a selling point of one ATS over another where there is a tangible difference in effective security / risk.