Jump to content
Security Installer Community

cybergibbons

Member
  • Posts

    498
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by cybergibbons

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

  2. The problem is that, and it is entirely your call, you only release some information whilst alluding to other products (unnamed) either having problems or inferring that they do.

    This is very misleading to the public in general and to those amongst us who are quick to castigate a product (or company) but then do a 360 degree turn based on something they read on the web without being able to validate the new 'facts'.

    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.

    But is it illegal? No.

    Is it factually incorrect? i'd say no because no specifics mentioned.

     

    In effect, no different to the bull put out by any other company or business.

    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?

  3. Hence the rhetorical question.

    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?

    Indeed it does. All return anticode 18003

    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.

  4. And therein lies the problem.

    Matt has formed a view that you did and duly posted.

    He has form for castigating a product in preference to another even when he may not be in possession of all the facts.

    Preference of one brand over another without starting why is not the same argument.

    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 argue that installers aren't in possession of all the facts - there are alarm systems that fall far short of the marketing.

  5. Question.

    What does military grade actually mean?

    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.

  6. One of the problems with what he's doing is it doesn't give a true reflection of products in general.

    Mentioning one brand/product specifically as secure whilst suggesting others that remained unnamed gives those who don't understand a false view.

    In effect, a potentially false but damaging reputation.

    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?

  7. CG-from your web blog .

    I'm not sure how you would get the seed codes. The customer doesn't know what they are. It's added to the account during commissioning. Or by the office direct to the ARC.

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

    Not sure how many of us have had a customer watch us while we program a panel. If its via UDL I doubt the customer would see anything more than the zone lists. And I'd say even if a customer was behind me whilst I was programming a galaxy he would miss what I'm typing I'm that used to which menu options to change etc etc.

    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.

    As others have said resetting the system yourself could potentially risk a URN loss.

    It also effects false alarm managment, and could cause more problems than its worth. -takes 5 mins to ring the arc for a reset providing the reason is genuine. If its not customer error, they have an issue with the system and need an engineer visit to assure the integrity of their security system.

    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.

    I tout technistore was a pay for product so posting a code generator would be against copyright?? Not sure if the actual algorithm is protected by that or not.

    Would make sence otherwise every one would have a copy of the generator??

    Reverse engineering for the purposes of writing your own code for interoperability is specifically protected in law in the EU.

  8. crackin work lads,hes posting on twitter how to defeat remote reset codes,oh and alarms in general....i hope your customers are reading..but were all keen to know how everythings works so its ok..

     

    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? 

  9. Really? I would have thought you'd need a lot more data than that.

     

    I suppose if you don't like your panel manufacturers anti-code you can disable it and use the RR input method.

     

    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.

  10. 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?

  11. Another question about impressions of security.

     

    I'm looking at anti-codes at the moment, which seem common on monitored systems.

     

    Typically this takes a 5 digit quote code along with a secret seed, and generates a 5 digit reset code (along these lines, anyway).

    It turns out for the few decoders I have now looked at, the secret seed can be determined from a one or two pairs of quote/reset codes. If this seed was constant across an entire installer or manufacturer, this could present a risk.

     

    What are your thoughts on this?

     

     

×
×
  • Create New...

Important Information

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