Posts Tagged Security

SRAMs’ wireless bicycle gear shifting: Protocol analysis

Aug 26, 2014 at 17:35 · Filed under Cycling, Technology ·Tagged , , , , , , , , , , , ,

It’s pretty rare that I get to blog about both cycling and networking. Hard to see how those two topics share any common ground. That’s about to change as SRAM, the American bicycle component maker, appear to have a wireless gear shifting system in advanced testing.

The system was seen at the Tour of California earlier this year, though disguised with decoy wires to make it seem like a wired, electronic system. It was also spotted recently at the USA Pro Cycling Challenge, now without the decoy wires.

You may ask, why on earth would bicycles need radio-controlled gear shifting? Which is a good question. One benefit seems to be that the wireless shifting weighs slightly less than either a conventional mechanically actuated system, or even a wired electrical one. However, that benefit surely will be very marginal. The lack of cabling may make installation and maintenance easier too. Perhaps. Another possibility is that SRAM were behind Shimano and Campagnolo in delivering an electronically controlled shifting system, and SRAM decided that going wireless would help differentiate their product from the other two. Who knows!

As someone who specialises in network protocols, I’m curious to know how it might work in terms of the messages sent, logical layers of the radio protocol, and how the different components communicate to co-ordinate shifting.

There are obvious questions: Is it secure? Are there any limitations? Will it be reliable? The brief answers to which are, yes it should be secure; yes, there seem to be some limitations over traditional shifting systems; and probably it should be quite reliable, however when it isn’t there could be quite strange behaviour.

The rest of this blog will go into the details of how this system works at a network protocol level, as gleaned from SRAMs’ patent on electronic shifting. It will look at the ramifications of the design decisions made, and also how this could affect the operation of the system in extreme circumstances where messages are lost due to, e.g., radio noise.

The quick summary:

The SRAM system, at least as described in their patent, has a number of limitations that are a consequence of the network protocol:

  • It can not support more than two front chain rings
  • It can not support intentional simultaneous shifting of front and rear dérailleurs

While radio noise is unlikely to be a significant problem, outside of deliberate interference or some unusual locations, should the system be affected by continued noise it may manifest itself as:

  • Missed rear shifts followed by an overshift of the rear
  • Overshifting rear shift, after an apparently normal front shift
  • Combined unintentional shift of both dérailleurs, on an intended front shift

The system should though be relatively robust against interference, due to its use of a low-bitrate network layer. It should be secure, due to use of strong encryption, so that only those with physical access to the bicycle (e.g. the rider) can control the gear system.

The system that goes into production may differ from the system described in SRAMs’ patent, and some or all of of these limitations may not apply to it. We won’t know till it is released.

Update 20150213: I’ve just noticed the very bottom of the SRAM patent mentions that the dérailleurs can transmit their current gear position. The patent mentions this might be used to allow the front mech to adjust its trim according to which gear the rear dérailleur is in. The patent does not mention this being used in the control protocol though, e.g. to have the dérailleurs ACK the shifter messages which could make the protocol more robust to missed messages. However, the hardware described in the patent is at least capable of this, and production systems could be enhanced this way. There may still be issues left in how the system appears to allow for shifting to be distributed over two shifters, I’d need to go back and re-check.

Read the rest of this entry »

Comments (10)

RBS and their bizarre new 3rd party credit check authentication system

Dec 18, 2012 at 12:59 · Filed under Complaints, Rants ·Tagged , , , , ,

Update: RBS have responded. The security issues apparently were some kind of system failure. I should have already been authenticated, using RBS specific questions, by the automated IVR you go through when you call – and I had gone through this. However, on my call, the system had lost this information somehow (there were computer issues on the day) and it wasn’t available to the  agent. Normally, the credit check based public-data questions should augment the RBS authentication procedures and provide an extra layer of identity verification. They are not normally meant to be the only form of identity verification, as appeared to happen in my call. With regard to the issue of that credit check data being completely incorrect, RBS have offered to pay any costs incurred in dealing with the credit check agencies.

RBS Card Services seem to have brought in some kind of new system to verify your identity when you phone them up. They girl said it’s provided by  3rd party credit checking agencies. They ask you questions that are based on quite public information – which is daft, as RBS hold far more personal, private data on me. Worse, in my case, it seems this information is wrong. None of the questions had any answers that had anything to do with me.

So RBS apparently don’t trust the security of the personal data they hold on me, instead trust external companies to identify me using public information. That doesn’t sound like competent or acceptable security to me.

Below is my letter to them, which will be sent tomorrow hopefully.

Read the rest of this entry »

Leave a Comment

Complaint to RBS Online about their browser whitelisting

Jun 15, 2010 at 23:51 · Filed under Technology ·Tagged , , , , ,

As part of my progression to grumpy old githood, I present what may well be the first in an irregular series of letters of complaints to large, hard-of-hearing organisations. It might not change anything, but it makes me feel better.

Dear RBS,

This is at least the 3rd time in a number of years where I have had to email you to tell you that your policy of white-listing browsers by their user-agents strings is somewhat less than conducive to both my financial interests AND my security. To remind ourselves of when I first encountered this problem. I also emailed you earlier this year on the 10th march, and I think I have suffered this issue on other, unreported occasions.

Read the rest of this entry »

Leave a Comment

Wisdom of Squid for More Security Sensitive Applications

Aug 4, 2009 at 21:27 · Filed under Technology ·Tagged , , , , , , , , , ,

CVE-2009-2621 was released last week. The issues seem to include a buffer-overflow, which implies a potentially easy remote root shell exploit1. So it’s perhaps worth repeating my previous claim that Squid really should not be used for security sensitive applications.

This is not to take away from Squid. As the swiss-army knife of web-caching/proxying software it’s awesomely valuable software. It’s just that building for security is somewhat at odds with software intended to be highly flexible and featureful.

Even if Squid’s code were 100% defect free managing its default feature-set remains a significant security problem. E.g. my own ISPs’ Squid-using Pædosieve still honours CONNECT to anywhere, proving just how hard it is to configure such software to disable unneeded features – and they were made aware of the problem many months ago. Prior to that they had forgotten to lock-down access to the internal in-band management protocol (accessible by using CONNECT proxying to localhost). They only recently disabled SMTP on the Pædo-sieve, possibly because they received email sent through it via the Squid proxy.

1. The bug report mentions this is triggerable via ESI, which I don’t think is relevant to a Pædo-sieve, but as it was in some generic string storage code there may well be many other paths to the bug.

Also, bugs were found in the HTTP header parser, where it will assert if fed a very large header. Relying on assert() is somewhat fragile, as these can be disabled by the compiler. Indeed, the fix for the ESI buffer overlow is to add an assert, it seems. Not confidence inspiring, security wise at least.

Leave a Comment

Good Password Hygiene

Jul 28, 2009 at 10:57 · Filed under Security, Technology ·Tagged , , ,

In a hypothetically perfect world, we’d be able to remember infinite numbers of passwords. However, for most people that’s not possible. Instead we have to find a way to make best use of that limited memory. Here’s how:

  • Do not use passwords that are easy to guess, e.g anything directly related to you, like your name or names of family/friends/pets/etc; or date of birth; or favourite colour,band,etc..
  • Ideally, use a longish random string as your password, of at least 10 characters (but longer is better).
  • The same applies for password-recovery questions, which often ask for information that is in the public domain (e.g. mother’s maiden name, date of birth). Do not provide real answers! Instead just make something up, or use another random string if possible.
  • Do not re-use passwords across different websites, unless you truly do not care about what is on those sites, and what they can do in your name with that password.
  • Do not be afraid to write them down if you can store them securely. E.g. if your home is reasonably secure, it’s fine to store most passwords on paper there. This goes against advice from many well-meaning, but utterly-wrong “experts”.
  • If you trust that a computer or device is sufficiently secure, it’s perfectly fine to store passwords on it, e.g. in a text-file. Also, many programmes support saving passwords and if you trust those programmes then it’s perfectly OK to use those features.
  • Consider using disk-encryption products like PGPDisk, TrueCrypt, BitLocker or the built-in capabilities of many Linux/Unix distributions (some of which offer this at install time) to protect your data with a master key. This is particularly recommended for laptops.
  • Any computer running Microsoft Windows likely can not be considered secure and should not trusted with more sensitive information. Portable devices should not be considered secure, unless their contents are known to be encrypted, and they automatically lock themselves after a small period of unuse (i.e. don’t trust your phone too much for storing sensitive data).

Basically, in an ideal world, all your day-to-day passwords for your various, online accounts should be unguessable, random strings;  you’d never have to remember any of them; you would just, at certain times, have to enter a master pass-phrase (which should be unguessable, but still memorable and much longer than a password) without which the passwords would effectively not be accessible.

Remember, security is a compromise between convenience and consequence. The ideal level of compromise will differ between different people, and between different situations. E.g., obviously, it’s probably a good idea to tolerate a good bit of inconvenience with your online banking login details and commit these solely to memory. If you have too many accounts to memorise the details, then store them very securely, e.g. buy a strong box or small safe, and obscure which details belong to what accounts – hopefully this buys enough time to contact banks and have the details changed if your house is burgled and the box stolen.

Common sense goes a long way. Unfortunately the “experts” you sometimes hear from don’t always have it.

Comments (2)