Jump to content
Security Installer Community

Vulnerabilities In Ip Alarm Signalling Protocols


Recommended Posts

  • Replies 95
  • Created
  • Last Reply

What product that is serious in the signalling world uses this cb?

 

Well - part of the problem is that those that rely on IP signalling don't seem to want to say what they use. Some deny using it, others won't comment.

As MrHappy has shown, Alphatronics own systems use it. 

 

ENAI who are also big in NL make receivers for this protocol.

I have a blog, some of which is about alarm security and reverse engineering:
http://cybergibbons.com/

 

 

 

Link to comment
Share on other sites

the interesting claim- send an alarm for all systems at the ARC w/o revealing an IP(I assume range of accounts on mass or randoms a/c) just need to know the receivers IP & ports no.s

if the protocol is weakness it won't just be the one manufacturer?

Mr? Veritas God

Link to comment
Share on other sites

As far as I know, the protocol is mainly used by Alphatronics gear, ENAI make receivers that support the protocol.

 

It doesn't look like the receiver cares about the source IP - only what is in the packet at a higher level.

I have a blog, some of which is about alarm security and reverse engineering:
http://cybergibbons.com/

 

 

 

Link to comment
Share on other sites

Well - part of the problem is that those that rely on IP signalling don't seem to want to say what they use. Some deny using it, others won't comment.

As MrHappy has shown, Alphatronics own systems use it. 

 

ENAI who are also big in NL make receivers for this protocol.

I think it's the best kept secret which 2 IP signalling platforms we use. :proud:

www.securitywarehouse.co.uk/catalog/

Link to comment
Share on other sites

I guess the thing is, how would anyone know if the protocol the use is actually secure or not? If they weren't, could they be updated?

Matt, I know at least one of the people you use takes security very seriously. Would still be interesting to have a go at their signalling though!

I have a blog, some of which is about alarm security and reverse engineering:
http://cybergibbons.com/

 

 

 

Link to comment
Share on other sites

I guess the thing is, how would anyone know if the protocol the use is actually secure or not? If they weren't, could they be updated?

Matt, I know at least one of the people you use takes security very seriously. Would still be interesting to have a go at their signalling though!

If you want to try a stress test I'd be more than happy to provide you with a unit into our receivers.

www.securitywarehouse.co.uk/catalog/

Link to comment
Share on other sites

I have no security concerns at all our preferred signalling is webwayone

 

The nerd in the video was asking for kit to play with, you sending him some new toys ?

Mr? Veritas God

Link to comment
Share on other sites

Even the top end TCD's can be compromised. Many are Linux based and once root is gained and init reset watchdogs bypassed, then a whole host of information is available to a would be attacker.

 

Nothing is 100% secure.  :(

Link to comment
Share on other sites

The SIA-HS protocol is insecure and should not be used. WebWay has never used this protocol.

 

We are happy to discuss our encryption and substitution protection with interested parties and have been independently tested not only by the BRE/LPCB, but also customers own IT and external penetration test houses. This has enabled us to sell our systems into banks and retailers. As encryption is part of our software protocol we see no reason not to offer this level of protection to any connection.

 

Encrypting at the signalling device

The critical point about encryption is that you must encrypt at the signalling device before transmission of the alarm or poll.

 

This requirement is laid down within EN standards.

 

Encrypting at the device is the only way to ensure that your alarms and polls are not being transmitted in clear (unencrypted) at any stage over the network between the signalling device, the host platform and the ARC - even then you need to be careful.

 

A short and non technical history of DES, Triple DES and AES.

From day 1 (around 2004) we have used AES128 bit encryption. AES128 is the "Advanced Encryption Standard". We use the 128 bit version which means we have 2 to the power 128 keys (thats billions and billions and billions (and billions) of combinations). AES is a standard written and maintained by the National Institute of Standards and Technology and has been adopted world wide by governments for the transmission of top secret data.

 

AES superceded DES and Triple DES Encryption (which was written in 1977). DES has hacked in 1999 by a computer in less than 2 and a half hours. Triple DES is considered generally secure, but can be theoretically hacked, hence the introduction of AES.

 

Encryption "outside the device"

When considering a secure signalling system or ATS provider ask them where the data is unencrypted and encrypted. If data is not encrypted within the signalling device then all alarms and polls will be sent over the GPRS service between the signalling device and the local cell (and further into the mobile providers network) unencrypted. Same goes for the transmission over PSTN to the exchange and potentially beyond. Intruders are far more likely to be positioned at the "local" interface to the premise and in a position to detect and read unencrypted data from the GSM/GPRS service or the PSTN line / ADSL.

 

 

 

 

 

Link to comment
Share on other sites

 

Encryption "outside the device"

When considering a secure signalling system or ATS provider ask them where the data is unencrypted and encrypted. If data is not encrypted within the signalling device then all alarms and polls will be sent over the GPRS service between the signalling device and the local cell (and further into the mobile providers network) unencrypted. Same goes for the transmission over PSTN to the exchange and potentially beyond. Intruders are far more likely to be positioned at the "local" interface to the premise and in a position to detect and read unencrypted data from the GSM/GPRS service or the PSTN line / ADSL.

 

 

How would we find this out though?

securitywarehouse Security Supplies from Security Warehouse

Trade Members please contact us for your TSI vetted trade discount.

Link to comment
Share on other sites

The SIA-HS protocol is insecure and should not be used. WebWay has never used this protocol.

 

We are happy to discuss our encryption and substitution protection with interested parties and have been independently tested not only by the BRE/LPCB, but also customers own IT and external penetration test houses. This has enabled us to sell our systems into banks and retailers. As encryption is part of our software protocol we see no reason not to offer this level of protection to any connection.

 

Encrypting at the signalling device

The critical point about encryption is that you must encrypt at the signalling device before transmission of the alarm or poll.

 

This requirement is laid down within EN standards.

 

Encrypting at the device is the only way to ensure that your alarms and polls are not being transmitted in clear (unencrypted) at any stage over the network between the signalling device, the host platform and the ARC - even then you need to be careful.

 

A short and non technical history of DES, Triple DES and AES.

From day 1 (around 2004) we have used AES128 bit encryption. AES128 is the "Advanced Encryption Standard". We use the 128 bit version which means we have 2 to the power 128 keys (thats billions and billions and billions (and billions) of combinations). AES is a standard written and maintained by the National Institute of Standards and Technology and has been adopted world wide by governments for the transmission of top secret data.

 

AES superceded DES and Triple DES Encryption (which was written in 1977). DES has hacked in 1999 by a computer in less than 2 and a half hours. Triple DES is considered generally secure, but can be theoretically hacked, hence the introduction of AES.

 

Encryption "outside the device"

When considering a secure signalling system or ATS provider ask them where the data is unencrypted and encrypted. If data is not encrypted within the signalling device then all alarms and polls will be sent over the GPRS service between the signalling device and the local cell (and further into the mobile providers network) unencrypted. Same goes for the transmission over PSTN to the exchange and potentially beyond. Intruders are far more likely to be positioned at the "local" interface to the premise and in a position to detect and read unencrypted data from the GSM/GPRS service or the PSTN line / ADSL.

Thats worrying as both the BT Secure & and as the BT Secure is the same hardware as Dualcom Calibre / UDL use triple DES then hardly 'secure' as the name implies . . .

www.securitywarehouse.co.uk/catalog/

Link to comment
Share on other sites

... I would also like to add that if your signalling device is dialling the digi receiver in the ARC as backup to GPRS (when GPRS fails) then this is delivered unencrypted and does not meet any of the standards. 

 

Sending the data over the PSTN to the digi receiver only means that the device is sending the channel from a particular site ID, but this is not hard to decipher.

 

Obviously delivering direct to the digi rack means the data is not encrypted as the operator ultimately needs to "read the data". Whilst the AMS will translate the data, this is not "decryption".

Link to comment
Share on other sites

... I would also like to add that if your signalling device is dialling the digi receiver in the ARC as backup to GPRS (when GPRS fails) then this is delivered unencrypted and does not meet any of the standards. 

 

Sending the data over the PSTN to the digi receiver only means that the device is sending the channel from a particular site ID, but this is not hard to decipher.

 

Obviously delivering direct to the digi rack means the data is not encrypted as the operator ultimately needs to "read the data". Whilst the AMS will translate the data, this is not "decryption".

Unencrypted digis. Whatever next :proud:

www.securitywarehouse.co.uk/catalog/

Link to comment
Share on other sites

James - you need to ask the individual providers simply whether they encrypt at the device or not and to put this in writing. 

 

You need to ask specific products and specific questions.

 

We can provide that and our test certificates from BRE/LPCB.

Link to comment
Share on other sites

I suppose various fans of various products can provide this info. Send it over to me and if anyone else can get it from their preffered we can compile a list.

I thinks thats a good idea :proud:

www.securitywarehouse.co.uk/catalog/

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.