Jump to content
Security Installer Community

Vulnerabilities In Ip Alarm Signalling Protocols


Recommended Posts

Posted

It's more than just asking about encryption. The devil is in the detail. Even though encryption is employed, the ARC receiving software and the transmitting device need to have unique keys in order that the ARC can verify the device before accepting the event for the account.  Many current 'secure' systems employ standard RSA&AES, but there is no identifying validaton of the transmitting device. Yes, this avoids eavesdropping, but does not stop the ARC being spoofed by encrypted events.

Posted

Triple DES isn't bad really as long as your key is not too short.

One of the keying modes uses the same 56-bit key at each stage, to maintain backwards compatibility with DES. It's technically triple DES but no better.

It has known issues that make it less strong that ideal, but none of the attacks are yet practical. As computers become more powerful they will be possible, hence the move away from them.

Most practical cryptographic breaks aren't actually in the algorithm itself, but the implementation. A lot of things have fallen over due to leaking information in padding, and key exchange is frequently mishandled.

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

 

 

 

Posted

GalaxyGuy - this was one of the things I mentioned in my post about encryption. Without a message authentication code, encryption is largely token.

 

Sorry, I've still to read it ;)

 

BTW, Honeywell employ 128 bit Private Key Advanced Encryption Standard (AES) for message data encryption and 1024 bit RSA (Public Key) for exchange of the AES private key on the Galaxy Ethernet implementation.  They don't employ message authentication, but their implementation of RSA is not standard, so any attacker would need to determine the algorithm to spoof events.

 

One other thing worth noting is that ARC's may employ blacklisting of any transmitting device that transmits to an unknown account. The sender would simply never know what was happening with the transmitted events, as they would be accepted. Wilco would never know this, as (for legal reasons) he didn't try spraying events across accounts at his ARC. If he had, then after the first invalid event, any subsequent events may have been binned. The ARC would then investigate the hacking.

Posted

Blacklisting is perhaps not a good way to describe handling for such events at most ARCs.  They would normally instead be redirected to a default holding account for investigation.

btn_myprofile_160x33.png


 

Posted

The blacklisting sounds like a great way of performing a DoS attack :)

 

 

Blacklisting is perhaps not a good way to describe handling for such events at most ARCs.  They would normally instead be redirected to a default holding account for investigation.

 

If they are accepted and flagged as non-normal reception and future reception is automatically blocked, then it sounds like a black listing. I would expect some anti-DDoS integration though.

Posted

Honeywell are entirely unwelcoming to reports of vulnerabilities. What has been their take on issues with their protocol?

To tell me to take a long walk off a short plank

www.securitywarehouse.co.uk/catalog/

Posted

Yeah. I got told to walk off a short plank with the chains of a big lawsuit around my ankles. 

 

I'll take up the offer of signalling equipment once my plate is clear, I have a lot on at the moment.

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

 

 

 

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.