StickNFind update

Posted on by

I have seen a lot of traffic today for StickNFind posts.

They’ve banned me from their Facebook page, blocked me on Twitter (which, is totally pointless) and stopped responding to email. I am sorry if I wasted your time with the survey as I have no way of communicating hundreds of people’s views to them now.

I suggest that if you have an issue with StickNFind you:

Essentially, the more noise you make, the better.

Encryption is only part of the solution

Posted on by

So, in the previous two posts I have covered:

And talked about how, although they are useful techniques to make an alarm better, they need to be implemented correctly.

Now, I am going to briefly cover encryption, and how it can go wrong.

What is encryption?

At a very basic level, encrypting something is encoding a message in a way which means an eavesdropper cannot determine the contents of the message.

There are many techniques – the one most familiar to people is a substitution cipher, where each letter is substituted for another.

In the real world, encryption uses more advanced techniques than this. Some encryption techniques are, to all intents and purposes, impossible to crack – unless you know the secret key, you are not going to find out what is in the message.

Sounds great! Where do I sign up? Many alarm manufacturers use encryption, and many don’t do it quite right.

Designing a good encryption scheme is hard

A famous saying is:

“Anyone can invent an encryption algorithm they themselves can’t break; it’s much harder to invent one that no one else can break”

Time and time again, custom built encryption algorithms have been broken.

Again, I’m sure there is a more concise saying about this, but I subscribe to this:

For a defender to succeed, he must have a 100% success rate against multiple attacks and attackers.

For an attacker to succeed, he only needs to succeed once.

What’s the solution to this:

  1. Use something off-the-shelf. There are mathematicians and developers who only develop encryption. Use their skills, don’t try to use your own.
  2. Open your code up – no encryption algorithm or implementation should be weakened by an attacker seeing the code. So open it up and let other people tell you the problems!

Encryption is often good in theory and fails in the implementation

Very closely linked to the above point – even if you use something off the shelf, make sure you use it right!

Common mistakes are:

  • Leaking key material by XORing the key with a constant padding value (in a previous post!)
  • Building a really strong encryption scheme but then failing to exchange the key in a secure way (i.e. you show everyone the key!)

Encryption by itself does not stop replay attacks

If the message “disarm the system” becomes “fodst, yjr dudyr,” when encrypted, there may be no easy way for the attacker to decode that message. Indeed, there would be no easy way for him to encode that message unless he had the key.

This may not matter though. You can infer what the message contains based on timing (the homeowner has just arrived, and pressed the disarm button), and replay the encrypted packet alone. You need to combine encryption with other techniques to ensure integrity and protect against replays.

Using a fixed key across all products

Again, this is partly the result of using a one-way radio system. Before the detector and panel can communicate, they need to perform key exchange, so that they both know the secret key. There are a few options here:

  1. You can send the key in the clear when paired and hope no one is listening.
  2. You can use a secure method of exchanging keys (like public key cryptography)
  3. You can program the key in during manufacture

Method 3 is attractive. On paper, your system is “encrypted” – you could even claim AES-128 encryption. But if that key is constant across every detector and every panel you sell, you have a problem. Why is this?

Firstly, you can never really assume that your code is safe. Whilst most modern microprocessors have some means of protecting code, this is by no means fail-safe. Sometimes designers forget to set the lock bits (well, quite often in fact), and the code can just be read out. Some PIC processors are vulnerable to a simple attack where you can recover 75% of the code from one device, and the remaining 25% from another (one manufacturer’s detectors have this issue). If you want to go further, you can decapsulate the microcontroller and read one-time-programmable memory visually – this is possible in the real world.

Secondly, it is sometimes the case that the alarm architecture means that I don’t need to know this key. Some alarms have an RF SoC performing all encryption – the main microcontroller just passes it simple unencrypted data. I can decouple the RF SoC and send my own, unencrypted data, and let the SoC do the hard work for me.

Thirdly, manufacturers offer firmware upgrades for download. These can contain the secret key material. It’s often easy to find – key material should look very random (more random than normal code). I have a simple tool to scan a file and graph entropy. It’s fairly easy to find key material using this, especially if you know how long the key is.

Using too short a key

One method of breaking encryption is to just try every single key and hope for the best – this is called “brute forcing“.

If the key is short, this process can be very quick.

Each time I add a single bit to a key, I double how many possibilities there are. A 1-bit key has 2, a 2-bit key 4, 3-bit has 8. This rapidly hits very large numbers – even at 32-bit we have 4294967296 keys. But modern computers are very, very fast – checking 100,000 keys a second is possible. That 32-bit key would fall in under 12 hours.

So key length has a big impact on how long it takes to perform this process. It’s now pretty much assumed a key length of 64-bits and under is too short to protect against brute forcing. But DES and other encryption methods still support 40-bit and 56-bit keys. If the option is there, people will take it.

Conclusion

Encryption is important in a wireless protocol if you want it to be genuinely secure – but it is only part of picture. If implemented badly, it can add little security and decrease reliability and usability.

Keep rolling, rolling, rolling

Posted on by

In the last post about technologies used in alarms, I discussed the use of spread spectrum. Another really common keyword seen on marketing material is “rolling code”. What is it, why is it used, and what problems are there with it?

Why?

A wireless alarm system might send a signal from a keyfob to the panel to say “disarm the system”. If the content of this packet does not change in any way from time to time, we could simply record this packet and replay it at a later time.

This is commonly called a replay attack. There are alarm systems available that are vulnerable to this attack – the older Yale Wireless Alarm systems (434MHz ones) and Friedland SL series are examples. There are “Universal cloning remotes” on eBay for less than £5 that will clone any alarm using 434MHz OOK signalling. You can also use an Arduino and cheap receiver to listen out for signals and store them for later replay.

It is desirable to have a means of stopping these replay attacks from happening.

There is nothing in the EN50131-5-3 specification that means a grade 2 alarm needs any protection against these attacks. Most newer alarms do however have some protection.

How?

The attack is possible because the signal doesn’t ever change – it is always “disarm the system”.

To protect against a pure replay attack, we just need to add something that changes each time the signal is sent. How about the time? “disarm the system 21:22:32 26/04/2013”

This works. There is now no way for me to record a packet and use it again later.

But a really malicious attacker could work out how to take a packet recorded earlier, modify the time, and replay it.

This is where rolling code comes into play – instead of appending the time, we add a code to the packet. This code changes each time a packet is sent. The receiver and transmitter have agreed how this code will change – generally using a psuedo-random number generator.

The packet now becomes “disarm the system 204389473692”, the next time it will be “disarm the system 937459384322” and so on.

The sequence of this codes is essentially random to an observer, and the code is long enough that it makes guessing the next one very difficult.

Unlike spread spectrum, this sequence is generally extremely long in small systems.

Keeloq is a proprietary implementation of a rolling code protocol, often used in car keyless entry systems. The rolling code is 32-bit, which essentially means it is impossible for someone to guess the next code.

Keeloq does have weaknesses. The major one is that it is possible to recover the key used to seed the random number generator. Once you have this, it is far easier to guess the next code. It’s still very challenging though.

What issues are there with rolling code?

Again, the devil is in the detail. Rolling code is a sound principal – but it must be implemented correctly.

Predictable codes

The whole thing falls over if someone can guess the sequence of codes you are using. There are a number of ways that this can happen.

If your code is short (say, 8bits), the an attacker has a 1/256 chance of getting the next code correct if he chooses randomly. If your code is long (say, 32 bits), then it is 1/4294967296. Whatever method you are using to guess the codes, you can clearly see that the longer the code, the harder it will be.

A good pseudo-random number generator (PRNG) can be seeded – you give it a key which determines how it will hop. It shouldn’t matter what the algorithm is or if the attacker knows the algorithm, as long as they don’t know the seed, they shouldn’t be able to predict the sequence. Unfortunately, many products either used a fixed seed across all products (this makes protocol design, especially with a one-way radio, much easier) or the algorithm is bad.

How can the algorithm be bad? Say we have a PRNG with this output when seeded with “1”:

7, 3, 4, 1, 3, 6, 1, 3, 2

If I were to seed it with “2”, the output should be completely different:

8, 3, 3, 2, 7, 1, 5, 3, 1

But some systems simply use the seed to skip some of the output i.e. with a seed of “2”:

3, 4, 1, 3, 6, 1, 3, 2, 8

Notice this is just the first sequence shifted along one digit!

If I know the entire sequence, then all I need to do is gather a few packets and I can work out where we are in the sequence. The number of packets I need varies, but with a poor PRNG or short code, it’s not very many!

Worse still, some “rolling code” systems use a code like:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

Whilst this might protect against casual replay attacks, it is not hard for an attacker to guess the next number.

Limitations with one-way radios

If your keyfob can transmit but not receive, there is a small problem. Each time it transmits, the code rolls forward. There is no guarantee that the receiver will hear the transmission.

This means that the transmitter’s code can be further ahead in the sequence than the receiver. This needs to be taken account of – what happens if you are idly pressing the disarm button in your pocket whilst waiting for the bus?

Most systems deal with this by checking for a valid code over a “window” of acceptable values. This could, say, be the next 256 codes. This has an interesting effect on guessing. If I have a 16 bit code, there are 65,536 possibilities. If the window was only 1 long, I would have a 1/65,536 chance of randomly guessing the code. If the window is 256 long, we reduce this by a factor of 256 – to 1/256. That’s a big difference.

Message substitution

A very simple rolling code implementation just appends the pseudo-random code onto the message i.e. “disarm the system 878463098273”

There is no link between the message (“disarm the system”) and the code (“878463098273”).

This means we can change the message and use the same code, providing that the receiver hasn’t received the code.

How could this be done? I’ll give one possible attack.

When you press “arm the system” on the keyfob, it will actually send more than one packet, to ensure that the receiver gets the message. We have something like:

arm the system 736474747363

arm the system 093219457437

arm the system 384838738383

arm the system 732878476655

If I am in the position to jam the receiver, but still receive the genuine packet, I can do the following:

1. Record all 4 packets.

2. Immediately replay the first two to arm the alarm so the user does not see an issue:

arm the system 736474747363

arm the system 093219457437

3. Hold onto the last two packets.

4. Change the messages on the second two packets to:

disarm the system 384838738383

disarm the system 732878476655

And bang, we have disarmed the system.

Replay attacks still work

As long as the packet never reaches the receiver, we can still grab a transmission from a keyfob and use it later. This means someone could press the disarm button on your keyfob whilst you are away from the house (say, when you pass your keys to the checkout assistant to scan your loyalty card), and then replay it later.

Conclusion

Rolling code, again, is a good idea, and if implemented well, can protect against a lot of attacks. Many systems do not implement it well though – the above vulnerabilities can be found in real world alarm systems.

A much more robust solution is to use timestamps in the messages and then use encryption and a message authentication code.

If anyone is interested, Atmel have a really good app note on implementing a secure algorithm with one-way radios.

The ups and downs and ins and outs of spread spectrum

Posted on by

It’s becoming increasingly common to see the terms “spread spectrum“, “frequency hopping” or “FHSS” on the spec speets for wireless alarm systems.

The question is, what does it mean and how does it improve a wireless alarm system?

We might as well start with the wikipedia definition:

Frequency-hopping spread spectrum (FHSS) is a method of transmitting radio signals by rapidly switching a carrier among many frequency channels, using a pseudorandom sequence known to both transmitter and receiver.

A diagram is a clear way of showing this:

Time vs channel

Time vs channel

This is a really basic example with only 5 channels. The channel changes for each time slot, and the hopping pattern is a rather predictable 4, 1, 5, 2 3. Both the transmitter and receiver know this hopping pattern and hop at the same interval.

Practical systems tend to use large numbers of channels (50 upwards) and hop frequently (hundreds of times a second).

This technique is used by Bluetooth and other technologies.

There is another form of spread spectrum called Direct Sequence Spread Spectrum, where the hops are faster than the data rate. This is rarely used in small embedded systems, but is used in WiFi.

What are the advantages of FHSS?

Resistance to jamming and interference

The most obvious advantage is that narrowband interference or jamming (jamming is really just intentional interference) will only cause a problem for one of the channels, so a signal can still make it through.

Jamming, I hope you like jamming too

Jamming, I hope you like jamming too

In the image above, there is interference on channel 2. None of the signal on channel 2 will be received, but all of the other channels are still fine. Even if you continue to use channel 2, 80% of packets will make it through.

Resistance to eavesdropping

At least at a superficial level, you could conceive that an eavesdropper would have to know the hopping pattern to be able to listen it to a FHSS signal. For this reason, some think the FHSS provides added security.

Transmitting with higher power

This is not intrinsic to the technique of FHSS, it is more related to regulatory requirements. A big problem with most ISM band radio systems is contention for channel access. The most common technique to avoid problems (without using spread spectrum) is to limit the duty cycle to 1% or below. This gives other devices a chance to use the channel.

FHSS avoids this issue as you are only using one of a number of channels in a group. Multiple devices can be using the same group of channels and it is unlikely they will want to use the same channel at the same time. Contention is less of an issue for this reason.

This is turn means that more devices can operate in a given area. The area a transmitter operates in is defined by it’s output power – a higher power can transmit further.

The lower chance of contention means that FHSS devices are allowed to transmit with a higher power, and hence tend to have longer range.

What are the problems?

It sounds like FHSS is a great idea. But, as always, the devil is in the detail.

You cannot rely on FHSS to provide protection from eavesdropping

If we take a practical example of one alarm system – this hops over 50 frequencies in the US version (which is the FCC’s minimum number) at a rate of 64 hops per second. This might sound fast, but it really isn’t.

The CC1110 RF SoC has built in support for FHSS. Using a technique whereby you pre-calibrate the frequency synthesiser, a hop time of ~75uS can easily be achieved. You can essentially turn it into a scanner – scanning all 50 frequencies as quickly as you can. This takes 3.75ms, a lot less than the dwell time of 15.625ms (1/64).

I might not be able to receive all of the packet – I’m going to miss at least some of the start of it – but I can receive some.

More to the point, I can record the hopping pattern. The design of most wireless systems means that this will never change.

The CCxxxx chips are used in a lot of alarm systems – from the low-end Friedland SL series to the high-end Texecom Ricochet. When they are used in alarm systems, they tend to be used conservatively – they need to work correctly all of the time. As a reverse engineer and hacker, I can push these chips to their limits and just hope that they work well enough to meet my goals once.

The same system mentioned above is sold in the UK but only hops over 4 frequencies. I don’t think this even meets regulatory requirements (another downside to self-certification), but it provides no protection against eavesdropping or even interference.

Predictable or simple pseudo-random hopping patterns

Both transmitter and receiver need to decide on a hopping pattern ahead of time. There are a number of techniques used to do this – you can store a predefined pattern in memory, or generate one using built in hardware or software.

A cold hard fact of pseudo-random number generation though is that the pattern will repeat at some point. This could be after 127bits or 32767bits or anything really depending on how it is implemented. Small embedded systems tend to use patterns that repeat after short periods though – PN9 (i.e. 511bits) is common.

This means it is entirely feasible to record the hopping pattern. It’s very likely this pattern will be re-used.

Some systems make it possible to look at the firmware and see the code that generates the hopping pattern.

Sequences are the same across all equipment

It’s hard to make every single device “custom”. This isn’t really a manufacturing concern – most devices are programmed at some point with a unique serial number. It’s more a protocol design issue – communicating a secret between devices ahead of time is hard work, especially on a one-way radio system. It’s also hard to work with 10 different transmitters using 10 different hopping patterns.

This means all detectors and all panels across every system made might use the same sequence. It only takes a small amount of effort for an attacker to determine this sequence and reuse it time and time again.

FHSS is complicated by other functionality

One of the advantages of FHSS is resistance to interference. As shown in the diagram above, if channel 2 is interfered with, we will only lose 20% of packets.

This is still a 20% packet loss – if other layers of the protocol aren’t designed to take account of this, it could totally cripple the system.

For this reason, many FHSS systems also employ adaptive frequency agility (AFA). If they detect a problem on a given channel, that channel will be taken out of use.

Adaptive frequency agility

Adaptive frequency agility

How could this be a problem? Well, how long do I take that channel out of use for? What happens if more than 50% of my channels are taken out of use? There needs to be some kind of mechanism to bring the channels back into use at some point.

The design of AFA algorithms is complex, and mistakes are made. It can be possible to game them into a state where they believe that most channels are unusable. A parallel to this is mesh networking routing algorithms  – you can sometimes game the system into believing there are no valid routes with only a few carefully crafted packets.

Conclusion

Whilst FHSS is a useful technique to improve interference and jamming immunity, it should never be relied on for security – that is what encryption and MAC is for.

StickNFind are a dishonest company – do not buy from them

Posted on by

The StickNFind stickers are available on a normal sales website. This is not crowd funding – this is normal sales. They are completely willing to take several hundred dollars off your hands for their tags today. There is no mention on the site of the tags being pre-release, beta, or in-development.

Yet they post this on facebook earlier today:

We have been reading the comments and wanted to address them. The StickNFind product is compatible with devices that support Bluetooth 4.0, Bluetooth Low Energy, and operate on Android 4.1. The SNF app is, currently, supports the Samsung S3, S3 Mini and Note 2. We are working hard to gain compatibility with the other manufacturers’ devices across the Android ecosystem.

We, in no way, are misrepresenting, conning nor scamming our supporters. The StickNFind product is still in the pre-release stages.

This is not acceptable behaviour at all.

The second a company needs to make a statement to clarify that they are not conning anyone, you know something is badly, badly wrong.

Please do not tell me that this is crowd funding – and I should expect this. They could have delayed the product so it worked (many, many tags are DoA or fail quickly) and they could have communicated the serious Android limitation

A review of Audiovox Insite BLE tracking tags – a competitor to StickNFind

Posted on by

The CEO of PhoneHalo, Chris Herbert, noticed some of my tweets about the problems I have been having with the StickNFind Bluetooth tracking tags, and offered to send me a sample of his competing product to review. This was very promptly shipped from the US and dropped onto my doormat on Monday morning.

The tag by itself

The tag by itself

The Audiovox Insite Ultrathin Bluetooth Proximity alarm, on the whole, is a much more functional product than the StickNFind. Let me go into some detail.

Firstly, the tag is very small. It isn’t as small as the StickNFind, but it is small enough to be used for the same applications.

inSite tag vs StickNFind

inSite tag vs StickNFind

The construction quality and plastic used are excellent and it has an integrated loop for attaching to keys. The battery fits on a small tray at one end. I can see that people might be confused which way the battery goes in, but the design protects against the battery being fully inserted incorrectly.

The app is readily available in the iTunes store for free.

Pairing the device worked easily – just insert the battery, and follow the instructions in the app.

The app only has a very small number of core features. I really believe this is why the Audiovox Insite tag works much better than the StickNFind tags.

The app

The app

There are two buttons:

  • Ring Device – this immediately causes the tag to beep and light up
  • Locate Device – this shows the last GPS location that the phone was in when the tag was in range.

That is all it has. No radar, no temperature. Very simple, but it works.

Two icons at the top of the screen show range (Close, Mid, Far) and battery level.   Generally the range is sensible, but it does jiggle around from time to time. It isn’t really that important, as none of the features rely on this.

As soon as the tag and phone are out of range from one another, the alert is triggered on both. There is no way of setting range – it is just in or out of range. It seems to me that they have admitted that any kind of range estimates will be poor, and have worked within this limitation.

So, what do I think?

  • The range is quoted as 30-60ft. This is very much what I am experiencing – it is in range anywhere in my house. StickNFind doesn’t even get to the other side of the room.
  • The connection does sometimes drop, causing false alarms. The tag automatically reconnects though. I have had a couple of disconnects a day when out and about. My cooker extractor fan seems to cause a problem – possibly it is electrically noisy.
  • The tag rings immediately when I press the button on the phone, every time, as long as the tag is in range. StickNFind only sometimes works, and with delay.
  • The beeping is far louder and more shrill than StickNFind. It makes it far easier to find the tag.
  • The app is stable and phone battery life doesn’t seem to be impacted.
  • Use of Wifi nearby doesn’t seem to impact range.

So, totally useless for tracking my cat, but it doesn’t claim to be able to do so.

I popped the tag open to see how it was constructed. The plastic is glued together and it was not possible to get the PCB out without wrecking the case.

The PCBs of the two products

The PCBs of the two products

The board is small and well constructed. Very thin PCB material. It would be possible to redesign it to be no larger than the StickNFind.

So, thanks to Chris for the sample. The Audiovox Insite tags don’t do what StickNFind claims to – but neither does the StickNFind. If you want to make sure you don’t lose your keys, camera, or phone, they do the job well.

Further communication with StickNFind about issues

Posted on by
Michael Manna, Social Media Strategist, recently recruited to StickNFind, contacted me to arrange a phone call to discuss the issues that myself and others were having. I didn’t think a phone call was a good way of furthering this matter, especially if there is one of me and many of them. This is my response:

 

I’d really like to keep this to email – it allows both parties to consider their communication better.

I want this product to work – which was why I started the survey to see how many others were having issues. I currently have 87 responses. I realise the sampling method is biased towards those with problems. To summarise the concerns of respondents, in approximate order of priority:

1. By far the biggest concern is not receiving the orders as expected. There are a lot of people who have not received any communication from you at all, and it seems some customers of sticknfind.com have received the product ahead of indiegogo backers. People are worried – the near silence on facebook and via email is rightly concerning – the words “con” have been used by several people. I have the product, I trust that you are shipping, just that it has overwhelmed the company somewhat. Your customers need to be kept informed.

2. The next biggest concern centres around the Android app. Many are frustrated that there is no app (or only a beta app). Again, poor communication means that many are not even aware there is a beta app, or that it will only work with a subset of phones. There are worries that it will only work with Android 4.1 or later, and not all phones/carriers will upgrade to this. People need reassurance. An email or slip of paper in the packaging explaining the situation would go a long way.

3. Many are reporting a range of <9m, or that the distance estimate is less accurate than expected. I am experiencing these issues. My gut feeling is this is a limitation of BLE, and there is no real way to avoid this. The promotional material very strongly suggests that much greater range is possible – I know my expectations were to be able to use them within my small terraced house.

4. There are some people reporting reliability issues. Certainly one of my tags doesn’t work any more, a few didn’t respond on arrival. I think this might just be the reality of hardware.

The common theme across all four of the above issues is that communication has been incredibly poor. I really hope your new role at the company corrects this, and I think it is really positive that you have already been engaging with people on twitter.

I’d be keen to know your thoughts on the above issues, but I think a response should be directed to the community rather than myself.

Unfortunately I have not had a response yet, outside of confirming receipt.

StickNFind update

Posted on by
So currently, the major complaints from users are:
1. No working Android app.
2. Shipping issues (no notification, delay, people receiving orders out of order)
3. Poor communication from company – enough time to come onto facebook to like positive posts, but not enough time to deal with support.
4. Tags arriving dead-on-arrival. Some of these then work after removing and replacing the batteries.
5. Tag range poor (<20ft)
6. Tags work intermittently – possibly related to battery connection.
7. Distance reading is very variable, making leash unusable.
8. Tags seem to have problems working in electrically noisy environments (i.e. a normal home).I’ve got over 100 people experiencing issues 4 though 8, yet none of us have received any response apart from “tap four times to wake them”. The hits on the blog continue to climb – I hate naming and shaming a new company, but your communication is so bad that there doesn’t seem to be any other way to get your attention.