cybergibbons

A few days late to this. The state of security on the wireless side is really quite poor for a lot of systems. The big issue is that most of them aren't two way, it causes so many issues. At this time, I'd only recommended Texecom Ricochet and Pyronix Enforcer. However, the RF side of things isn't my big worry anymore, it's the signalling and IP side. So many companies are doing this wrong, and badly wrong. You can divide the manufacturers cleanly down the middle. There's those burying their head in the sand and those that are seeking out best practices.

Thanks for the link to my site. I still stand by those recommendations.

Didn't know they existed!

Anyone else?

Surprised that there are the even older white ones out there. Thanks.

The CSL boards I've been looking at are nearly all CS2300 Dualcom GPRS units. It looks like there are now other boards available: CS2121 Dualcom DigiPlus CS2300-R Dualcom Gradeshift (which outwardly looks like the CS2300) CS5600 Dualcom DigiAir And at some point there have been: CS5300 Dualcom Calibre (black box)I'm being told that any issues I find on the CS2300 units aren't going to be problems because there are very few of the units out there. I don't think this is true - I think the CS2300-R is just a minor revision and the CS5600 DigiAir is too new to have already replaced however many units there are out there. What units do you see in use?

Ah, cool. Glad that it was informative.

Not an installer, just someone who plays with alarms. I don't see the point in going for a 1-way system anymore. Scantronic Ion is pretty poor, vulnerable to jamming (intentional or not) and replay attacks (read this PDF on the Abus Secvest http://sitsec.net/files/secvest_analysis.pdf, Cooper have verified the same protocol is used with Ion). I wrote about the differences between one and two way systems from a technical perspective a while ago: http://cybergibbons.com/alarms-2/alarm-technologies/it-swings-both-ways-especially-for-rf-comms/ The Pyronix Enforcer is pretty good I think, but I think I prefer the Texecom Richochet gear. I like that you can use Wintex (PC interface software) easily with Texecom. The design of the system, electronically, is much more compact and looks like it was done from the ground up, whereas the Pyronix gear looks a bit hodge-podge.

Some of the outputs are pre-set to mirror other signals in the alarm.

The biggest problem by far is the small key compared to the code size, so I've kind of stopped looking into this one.

The same is true for encryption in some wireless systems. The receiver in the panel doesn't have the overhead to deal with a key per detector, so it just uses a single system wide key. That means all detectors, ever, use the same key...

Thanks. With a) it seems that the main issue is that customers could reset the panel when the ARC doesn't want them to. b) I suspect exactly the same algorithm is used in the panel as in the program. I think the algorithm was written for whatever 8-bit processor was used in those days. Might as well show the algorithm used, the only bit of it that needs to be secrete is the vector at the top which I have changed. I don't know if you know any programming or python, but it's really simple. # Taken from the data in the exe vector = [3,3,5,5,8,1,3,9,8,0,5,9,3,9,4,1,1,0,9,4,3,0,2,2,8,4,3,2,8,4,9,4,1,3,3,3,3,8,5,3,0,2,4,3,2,1,8,9,0,5,4,3,9,5,8,3,9,9,1,0,0,9,9,3,3,8,2, 1,4,9,1,4,9,2,9,0,9,5,3,9,5,3,3,5,9,1,0,2,9,3,2,1,2,9,8,0,4,9,4,2,3,9,4,0,1,8,5,3,3,9,9,1,0,5,9,3,8,9,4,8,4,2,3,1,0,3,9,4,8,2,0,4,3,3, 1,0,5,2,8,3,3,5,2,8,3,2,9,5,2,1,2,4,4,3,0,4,2,3,4,1,8,2,9,1,0,5,1,8,2,4,3,5,1,0,3,8,5,3,2,1,1,3,9,3,2,3,5,8,3,9,0,3,2,3,5,3,8,4,0,3,9, 1,9,3,0,2,9,3,8,1,4,2,8,4,0,1,9,1,0,1,2,1,3,5,3,3,9,0,2,1,4,1,2,3,4,3,4,9,5,3,5,9,3,1,3,9,4,0,3,2,3,3,4,4,2,1] def generate_reset(quote, version): i = 0 tens = 0 reset = [] while i <= 4 : j = 0 result = 0 while j <= 4: offset = (version + tens + quote[j]) % 256 result = result + vector[offset] tens = tens + 10 j = j + 1 reset.append(result%10) i = i + 1 return reset print(generate_reset(quote = [0,0,0,0,2], version=131)) Notice that there is no multiplication, division, or anything fancy. The % symbol means "modulus" which most people know as "remainder". So "% 256" means "divide by 256 and give me the remainder". You normally get this for free in a microcontroller - an 8-bit number is limited to 256 values, so it just wraps round anyway. Panel firmware would contain it - in fact, now that I know certain panels have it, I can find the long string of characters called "vector" in some of them. The problem with panel firmware is that it is very hard for me to work out what is data and what is code. In x86 exes, there are normally a lot more hints available to me. I can also easily run an x86 exe and step through the running code to see how it works. With a microcontroller in an alarm, I can't easily do this.

Tunstall are someone who Menvier took over who Cooper took over? If you can point me towards a program to generate them...

Precisely Joe. This is just an easy target to show that.

It's all part of learning. Nothing lost for a few hours work.

So I wonder what drove the standard to require that and where the 5-digit Technistore code fits in to this? There must have been some reason behind it being 5-digit - it's rarely seen as a code length. It's a combination of the long code and short key. The key allows 256 distinct mappings between the quote code and reset code. That means that 12345 quote can only map to at most 256 of the 100,000 possible output values. 999,744 of the outputs are not possible - our keyspace has been reduced hugely. Notice I say "at most 256". It is possible for 12345 to map to 98765 using one or more keys. In fact, 12345 could map to 98765 using all 256 keys, but then we wouldn't need to find out they key at all. So if you tell me the reset code and I know the quote code, it is highly likely that I can just guess the key. For a very limited number of quote/reset pairs, I get 2 possible keys (in fact, there are two combinations with 4). So more than 99% of the time, I just need a single quote/reset pair to work out the key. So normally I get something like: 12345/74643 - only possible key is 123 (99.25% of the time) Sometimes I get this: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 98747/37265 - one possible key 232 (about 99.25% of the time) It would be really unlikely to get this: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 91737/72764 - two possible keys 078 and 154 (about .75% of the time) (we know the key is 154 as it is the only common one) Vanishly small chance of this happening: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 73748/38377 - two possible keys 232 and 154 (about .75% of the time) 98747/37265 - one possible key 232 (about 99.25% of the time) I've just tested these by running every single possible combination of key and input code against the algorithm. Not in any detail - have started looking at Texecom. Not aware of Tunstall.

Thanks Matt. You've raised something interesting there. With the 00-99 mapping system, you'd need to get all 100 pairs to be sure of the mapping. With Technistore, you need one pair to know the mapping.

My point is that someone, for some reason, decided a simple scheme of mapping 00-99 wasn't adequate. A much more involved scheme was developed, Technistore. This has the illusion of being more complex/secure, but once the algorithm is known, it is equivalent to a 000-255 mapping. The key is easy to derive from a single quote/reset code, and once the key is known, that's it. It is easy to develop a 00000-99999 mapping that uses a decent key length (128 bit is ideal, even 16 bit is much better) that would get rid of these problems. It wouldn't have required any more effort. It would have looked complex/secure, but also been secure, unlike with Technistore. Installers and ARCs don't seem to like the idea of customers resetting anti-codes themselves, so there has to be a security aspect here. Is it really a problem how bad Technistore is? No, not really. But what does it show? 1. Things can give an impression of being better, but they aren't really. 2. End users don't really have any way of knowing if things are better or not as they don't have the tools, knowledge or skill. 3. Some people developing alarms seem happy with this being the status quo. If I can write "AES-128" on my box, that's all they care about.

The way I see it, there are several stages this system has gone through: 1. Customers were allowed to reset alarms themselves. ARCs didn't want them to do this - what's the reasoning here? 2. A simple 00-99 quote and reset code system was developed and used by several panels. Someone must have deemed this inadequate because a more complex system was developed. Why was this required? 3. Technistore was developed which claims "military grade encryption" is used, and looks like it is licensed out to alarm manufacturers. So, the complexity of it has moved forwards incrementally over time. What was the reasoning for moving forwards? Were people finding that the 00-99 codes were being bypassed by customers? Or, in reality, was it just Technistore looking to make some money by artificially creating a need for security round this process?

How long is the anticode though?

How does the UDL software authenticate with the panels?

It is almost always without exception a bad idea to "roll your own" encryption: http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own It's also a really bad idea to keep encryption schemes secret - the security should lie in the key, not the algorithm. If you keep it secret, the most clever person to look at it is going to be you. Make it public, and there is almost always someone more clever than you to take a look. I partly understand why Technistore is like this - it was implemented for embedded systems 25 years ago. Even with that in mind, it's got issues.

One of the big reasons I am here is to make sure anything I infer isn't false.