Design Puzzle – Increase Car Security

Posted on November 27, 2017 by Dean Dretske

I saw the following video this evening.  It shows a pair of car thieves spoofing the car-key conversation to unlock and steal the car.  I thought it would make an interesting design problem to talk about.  Although I mostly design software systems, I get involved with hardware while solving some process issues.

https://www.youtube.com/watch?v=S66TOcpVD50

From the video, it appears that the thieves are using a man-in-the-middle attack on the conversation between the car and the key.  The box near the car looks like the key and the box near the house looks like the car.  To the real key and real car, the boxes seem like their real counterparts.

Often convenience (e.g. not needing to pull your key out of your pocket to get in and start the car) is gained at the expense of security.

Here are some ideas that would make this MitM attack harder:

1. Make the key invisible to the the box outside the house.  This could be done by placing it in a container that is impervious to RFID(?).  Or have another object next to the key storage that scrambles the RFID signal – there are similar devices (Armourcard) to put in your wallet to keep your credit cards from being scanned.  I assume that the key works with RFID, but it may be a similar protocol.

2. Make the key smarter by adding sensors.  The key could be silent unless it is above a 85 degrees (in a pocket) or unless it moved in the last 10 seconds.  Either of these sensor additions would prevent this MitM attack.  I don’t know if the current keys have batteries – the addition of sensors might require it.

3. Add another layer of security in the car.  High level biometric controlled locations often need 3 things to gain access: (1) something you have, (2) something you know, and (3) something you are.  For example, a badge (1), a password (2) and a handprint (3).  In the current car system, the only requirement is (1) something you have – the key.  The car could be modified to require a password or a thumbprint (like your cell phone).  Since most higher end cars already have touch screens, it would not be hard to add either requirement.

Any other suggestions?

Posted in development | Tagged , , , , , | Leave a comment

Developer Rant – Interruptions

Posted on February 11, 2016 by Dean Dretske

— Originally posted on LinkedIn —

It is a joy to write good code.  Code that solves the problem in an elegant way.  Code that is easy to maintain, easy to expand as new features are desired.  But it can also be hard to write.  It takes time, focus and understanding of the problem.

There are things that we can do to make it easier to write good code.  Unfortunately, we can also do things to make it harder.  A lot of developers work in places that make it harder.

In order to create good code, a developer needs to have some periods of focused thought.  She needs to get in the ‘zone’ – where she understands the details of the problem domain and the evolving model of the code for her solution.  She can get a lot accomplished in a couple of hours of zone time.  However, interruptions can make this difficult.  Researchers have found that it can take up to 15 minutes to get back to the same level of focused concentration after an interruption.

So, a good development environment will allow a developer to have blocks of time (2-4 hours) of uninterrupted time.  But many offices don’t support this.  Instead, the environment:

  • expects a developer to respond to emails rapidly.  The worst I have seen was a set of business analysts that would call on the phone if they did not get an email reply within 5 minutes.  I have also seen many invitations to meetings that are scheduled to start within the next hour.  This cultural demand for instant replies affects developer productivity.
  • schedules daily meetings at inappropriate times.  When core hours are 9 to 4, it is better to schedule a daily meeting for 9, or 1 rather than 10:30 or 2.  This gives the developer a better chance to get in the zone and stay there for a good block of time.
  • places their developers in noisy environments.  Open cube farms are noisy.  You hear everybody’s conversations.  It is difficult to get in the zone with that many distractions going on around you.
  • uses meetings to convey information that could be sent as an email.  Meetings should be for discussions, back and forth.  However, many meetings are a data dump from the manager – this data dump is much less intrusive if sent as an email.

Is your environment supportive for you as a developer?  What element of your environment could be changed to make it more supportive?

Posted in development | Tagged , , , | Leave a comment

The Accident Reminder

Posted on July 31, 2015 by Dean Dretske

— Originally posted on LinkedIn —

On my way to lunch, I heard that uncomfortable sound of two cars colliding. From the distant glance, it looked like there were no injuries and the parties were starting to talk.

A few minutes later, on my way back to my office, the cars were still in the intersection. The parties were now both on their cell phones. I was walking toward one of them when I noticed that her hands were shaking and she was bleeding from the back of her right hand. She was sitting on the edge of the sidewalk as she hung up from her conversation. I mentioned that she was bleeding.

As she blotted the back of her hand with a napkin, she started talking about the accident. She said that her car was fairly new and that she had noticed the flashers were on as she was driving. She got focused on turning them off and the collision happened. We chatted a bit until the fire truck arrived and she moved over to get her hand checked.

As I walked back toward my office, I thought about the conflict between ‘keep your eye on the ball’ and ‘always be aware of your environment’. We all have that problem from time to time. Pilots have crashed airplanes while futzing with an indicator light in the cockpit. Trackers have been so focused on the tracks they are following that they get ambushed by their quarry.

Many developers focus only on their own project and ignore the other projects that their company is developing. Without this awareness, how can the developer recognize the shift in technology that their company may be realizing. Or the shift that the industry is taking while their company focus is too narrow.

Or the developer may be able to add value by suggesting code reuse between his project and another.

Although the laser focus is needed to solve some problems, keep a balance between the laser focus and the environmental awareness. Or you may collide with part of that environment.

Posted in Personal | Tagged , , , | 5 Comments