Jump to content
cybergibbons

Vulnerabilities In Ip Alarm Signalling Protocols

Recommended Posts

James..I agree that you to need to differentiate the products in some way and this is generally in the reporting times and maybe other "tangible" features and benefits. But if we stick to the title of this topic here, encryption and substitution techniques are fundamental to how a communications system (or Alarm Transmission System in our case) is developed. You work out how your product is going to signal from a to b and once you have that you use that technique across all your products.

 

Operationally, to differentiate on this level (encryption and substitution) would be a nightmare to "police and maintain". In this area we never compromise on the security of the communications whether it be a lowly "digi" type product or a full blown LPS1277 unit. Its a standard feature.

  • Upvote 1

Share this post


Link to post
Share on other sites

Sorry..forgot one point you raised.

 

Ive no problem at all in anyone getting an SPT and trying to compromise it. The BRE and DNV Certification we have to LPS & EN50136 (and shortly EN50136 tested to System 5 via CertAlarm) should give confidence to anyone using our systems and save them the effort.

Share this post


Link to post
Share on other sites

Couple of points I've read ...

 

Grade differentiation

Some people say how do you differentiate between Grade 2, 3 and 4. With regard to encryption and substitution protection we don't see any point in not providing the feature whatever the Grade. For us the clue is in the name of our market sector "Security". Additionally it is hard enough to manage the annual/monthly billing processes with ARCs for products and Grades, adding encrypted or non encrypted would add another layer of difficulty (and consequently cost).

 

The only decision you have to make with our products is what reporting times for dual path failure are you comfortable with (24 Grade 2, 11m Grade 3+ and 3.5m Grade 4). The encryption and substitution protection are all part of the standard service, independent of Grade - it's core to our software.

 

Substitution protection

Both the device and the messages require substitution protection under EN standards. We have employed this in our system from day 1. The protection has been tested by BRE/LPCB UK, DNV Norway and we will have our CERT Alarm Certificate during May/June. Obviously the receiver must decrypt the message and determine whether any substitution has taken place (in our case and most ATS providers the receiver is an integral part of the ATS).

Share this post


Link to post
Share on other sites

Sorry..forgot one point you raised.

 

Ive no problem at all in anyone getting an SPT and trying to compromise it. The BRE and DNV Certification we have to LPS & EN50136 (and shortly EN50136 tested to System 5 via CertAlarm) should give confidence to anyone using our systems and save them the effort.

Interesting. If CG want's to try it into our receivers I'm happy to accommodate. Your competitors refused to allow such test. This says a lot.

Share this post


Link to post
Share on other sites

A test is not a problem. 

 

Prior to any test we would need to understand who wants to test and whether that test is an impartial one or funded by another party/competitor.

 

For this reason a face to face meeting, NDA and written disclosure of 3rd party interest is required.

 

Thanks, Chris.

Share this post


Link to post
Share on other sites

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 **** :(

Edited by cybergibbons

Share this post


Link to post
Share on other sites

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 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).

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.

Edited by cybergibbons

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!).

Share this post


Link to post
Share on other sites

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

ha ha ha lol

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I think if the way some so called high end comms devices mechanisms were known then a lot of people would worry about their preffered supplier. Then worry about who would get sued 'if' the break in occurs,

Share this post


Link to post
Share on other sites

Just to brighten your day ... the slippery slope of reducing security, non compliant installation, no encryption and long reporting times would result in a less well managed system, with more incidents. Whilst end users could benefit from "lower costs" the reduction is returned to the installer/keyholder/insurer as a cost which they have to bear - that's whey there are standards there to help the professionals sell a service instead of a bag of nuts and bolts.

 

A simple and very sad tale below which is in the press now ... in summary a family buys their 14 year old boy a bike, the brakes are not tightened correctly, the boy ends up out of control down a hill and is killed on the A4 by a van. Nobody saw it coming, but if the basics had been got right ... none of this would have happened.

 

Get the core of the solution right. Stick to it. Nobody gets hurt.

 

 

Kadian Harding inquest: Coroner raises bike safety concerns
_67329808_67329803.jpgKadian, from Steep, in Hampshire had been out on a ride with his family when the accident happened

The coroner for Wiltshire and Swindon is to ask accident prevention charity Rospa to highlight the need for brake safety on bicycles after a boy's death.

David Ridley made his comments at the hearing into the death of 14-year-old Kadian Harding who was hit by a van in July last year.

The front brake failed as Kadian, from Steep, Hampshire, cycled down a hill near Marlborough.

Mr Ridley recorded a narrative verdict at the inquest in Salisbury.

He said he would contact the Royal Society for the Prevention of Accidents detailing the "lessons learned" to see if anything can be done to raise the awareness of getting a bike checked before it is first ridden.

Summing up at the inquest Mr Ridley said the front brake suffered a "complete catastrophic failure" due to the pinch bolt "more likely than not being sufficiently tight" and causing the cantilever not to function at all.

'Perfectly safe'

Kadian had been out on a bike ride with his family on the day he died.

He was riding down a steep path with five other people, including his father and aunt, when he was unable to stop as he approached the busy A4.

During two days of evidence, the inquest heard the teenager had taken the bicycle to a shop close to his home in Hampshire on at least two occasions in the weeks before his death.

On the day he died, Kadian had taken the bicycle to a shop in Marlborough, having been told to get the brakes checked by his father.

Mr Thomas Harding, an experienced cyclist, told the hearing: "I specifically said 'we are really concerned about the brakes. You must get the front and back brakes looked at.'

"He said they looked over all the brakes and replaced a cable. I didn't have a go [on the bike] but I did try both front and back brakes.

"I noticed they were much firmer."

Philip Birkett, owner of Acceler8, said Kadian had asked him to look at the gears and the rear brakes.

"I stand by my work and everything I did was correct. When that bike left the shop it was in a perfectly safe condition," he said.

 
 

Share this post


Link to post
Share on other sites

By the way, if anyone at WebWayOne thinks the post has anything dodgy in, I'll change it. None of the statements refer specifically to your system, they are just inferences, but I could see how someone could link them.

Share this post


Link to post
Share on other sites

So the WebWayOne doesn't use ARM, it's a Freescale Coldfire processor. Some of these have a really good hardware encryption block that does AES and DES very easily and quickly. I don't think I've looked at two bits of alarm equipment with the same processor in it!

Share this post


Link to post
Share on other sites

I haven't seen anything "dodgy" in your posts. This is a great subject. As an ATS provider we have to be able to sell a secure solution in volume.

 

The cost of the solution is a combination of development, hardware, software, support services and administration (hardware invoicing and ongoing billing). 

 

As a service provider you can build in alot of unforeseen cost by having too many variants of a solution. That's why we build a core platform that's as secure as we can make it for the money. Just so happens that by selecting the right hardware footprint you can pack in alot of security and still meet the market price points.

 

Getting the AES or other encryption standard in there is the first part - but you then have to manage the key creation, distribution and 24 hour "randomised" (lets not get started on what constitutes random) key change.

 

We often say "if it was that easy we'd have finished this thing years ago" (generally referring to creating a pins only IP clone of a Redcare or CSL. However integration and the solution management of any signalling technology (PSTN, GPRS, 3G, Wi-Fi, IP) requires rigour and the right communications professionals.

Share this post


Link to post
Share on other sites

That's another point - a lot of systems have fallen over on encryption before due to poor random number generation (calling rand() with a fixed seed isn't uncommon).

Edited by cybergibbons

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×