cybergibbons

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.

I don't recall any point where I haven't given enough evidence to back up a claim about a specific product. If I haven't named the product, it is because the manufacturer has made it clear they would be interested in legal action, so I need to be careful. The system that I didn't name that I don't think is good, I provided a document describing a similar system, and asked you to make your own conclusions. Open up a Scantronic wireless panel, look at that document, compare the radio modules, make your own judgement. I don't know. I'd question the use of the word "encryption" under trading standards. If your signalling system claimed it was encrypted and it turned out to be as weak as this, would that not be of concern?

Technically it's not encryption either. So, on a marketing and technical level, it's pretty bad. Where's the line? "This alarm uses rolling code" and the rolling code is 1,2,3,4. Is that dodgy? So if I am allowed chosen plaintext (i.e. I can call up the ARC and tell them whatever quote code I chose, and get a response), then it wouldn't require many pairs to get the keys. I don't know how possible this would be, as I think they would have to see an alarm activation, which means I would need a real quote/code pair. If it's only known plaintext (i.e. I am using valid quote codes generated by the alarm), it would be quite a lot more pairs required. Still a tiny number compared to the security a 2048-bit key affords. All of this would have been caught by an undergraduate doing a cryptography coursework "Is this homebrewed MAC secure?". It wouldn't have been hard to make this secure at all. Actually, I think it would be less effort just using something ready made.

How do I change that though? I've looked at a good few systems, enough that I can form an opinion of where they lie in terms of security. I've posted information on why I think the bad products are bad, some of which has been in quite a lot of depth. I can go into more depth, but as many have said, it would be beyond them. I can that installers aren't in possession of all the facts - there are alarm systems that fall far short of the marketing.

Absolutely nothing, it's marketing. It suggests it would be a standard that the military could use, which suggests it might pass some standards that the military have. If any of you have Technistore in front of you and it is a version where you can change the seed, try this: Seed 100, code 33333 Seed 101, code 22222 Seed 102, code 11111 Notice how they all produce the same unlock code? It's leaking information - changing outputs in a predictable way like this shouldn't produce a predictable output. I think, but I am not 100% sure, than it would only take about 50 valid reset/code pairs for me to determine the seed and the far longer initialisation vector (256 bytes). So even if the key was much longer, the algorithm sucks.

I don't think I have said that one brand is secure really, just my impression of it is better than others. Is it any different to an installer saying they prefer Texecom over Honeywell?

For Technistore, on average you need just one quote/reset code pair to derive the seed code. About 0.25% of code pairs lead to two valid seeds, and less than 0.01% generate more than that. So after a single reset, you have the seed for your panel, and it seems quite likely the seed for all alarms on the same ARC (correct me if wrong, there are quite a lot of references to the seed not varying on a per-customer basis). Like I say, the key length is so short that you can normally recover it with a single quote/reset code pair. No need to spy on the installer. So what if it isn't genuine? The point is that this mechanism is touted as secure ("a military strength data encryption algorithm") and it isn't. There isn't a need for it to be insecure, this is just bad code. Reverse engineering for the purposes of writing your own code for interoperability is specifically protected in law in the EU.

There's money in reverse engineering, trust me.

Which one is it then?

You'd still need a lot of skill from anything I had posted to be able to defeat the anti-codes. On one hand I am being told that these issues I'm pointing out aren't real vulnerabilities, on the other hand I'm being told that they shouldn't be published?

Changed to reset, sorry.

I've just updated the blog with my findings from the reverse engineering of Technistore, if anyone is interested.

The key would need to be longer than the pin for it to be difficult. With it being so short, it's really not hard.

Thanks, I guess?

So I guess I need to start ripping UDL software apart now?

Technistore and one other. Not wanting to name as I can't openly source it.

It's a hard one to make better though. If you are limited to 0-9 on 5 digits, it can only be so secure, but a seed at least as long as the reset code would make it better.

It's easy to bypass that check with a debugger, and then it just seems to be a 0-255 code.

That's interesting. With no seed, the only protection is keeping the executable secret. Technistore allow you to download it from their site, oddly.

This is the thing - it is virtually impossible to secure an executable such that you can't get the algorithm out. The security has to be in the key (the secret). If the key is only 8 bits, then guessing it isn't going to be hard. Have their been many changes in anti-codes recently? Do new panels have new decoders? Which standard or body is it that dictates how anti-codes are used?