Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] A Little OT: The Password Post-It



Richard Pieri wrote:
> The transceivers don't need to be Bluetooth. They just need to operate
> on the same frequencies that Bluetooth uses.

I got that. It doesn't make the task of building the transceiver easier,
unless you happen to be an analog RF engineer. It may even make the job
harder to approach it purely as an analog signal relay, as you won't be
using off-the-shelf Bluetooth modules.


> The hard part isn't the signal processing.
> It's the frequency hopping.

Looks like BT uses 79 frequencies. You could always brute-force it and
have 79 tuned parallel channels in your transceiver, or just use a wide
band transceiver that encompasses the frequency range. The point being
the transceiver doesn't necessarily need the intelligence to track the
frequency hopping.


> More details:
> http://www.isoc.org/isoc/conferences/ndss/11/program.shtml#id2a
> 
>> Relay Attacks on Passive Keyless Entry and Start Systems in Modern
>> Cars
>>
>> We demonstrate relay attacks on Passive Keyless Entry and Start
>> (PKES) systems used in modern cars. We build two attack realizations,
>> wired and wireless physical-layer relays. They allow the attacker to
>> enter and start a car by relaying messages between the car and the
>> smart key, independently of the presence of authentication and
>> encryption. 

As I expected, an academic proof of concept.


>> ...propose a set of countermeasures.

Did you read the paper to see what the proposed counter measures were?


> Geofencing has a number of serious drawbacks.

While it's always good to know the limitations of your security
measures, and it makes for interesting conversation, we're getting into
the realm of absurdity here with respect to the level of security one
expects to get from this sort of solution.


> Second is that GPS reception indoors is often nil making it impossible 
> for the app to detect its absolute coordinates.

True. But I think if this:

> The fob could be in a different room...

is a requirement, then your security needs exceed what can be provided
by a wireless two-factor solution. Use a wired smart card.

I expect most people would be satisfied just knowing the phone is in the
right building. Presumably using a device you already have on your
person and that authenticates without manual intervention makes this
convenient enough that you'll get good adoption rares with minimal
complaints. If you've got tech people that need higher security, have
them carry smart cards.

However, this:

> ...a different building...

could be addressed by having the smartphone app fingerprint the WiFi
access points in the vicinity. Maybe even verifying that the phone has
an active connection to the corporate WiFi, authenticated through your
RADIX server (the laptop/desktop component could also confirm this).

You've now raised the bar some more.


> DGPS has a positional (horizonal) margin of error of +/-5 meters...

Then there's Bluetooth to the rescue:

http://architecture.mit.edu/house_n/documents/CheungIntilleLarson2006.pdf

  A Bluetooth-based indoor positioning system using off-the-
  shelf low-cost stationary beacons and mobile host devices
  is described.
  [...]
  The system should work robustly, determine location at
  the scale of rooms and workspaces (i.e. 2-3m), and update
  quickly enough to capture movement trajectories of people.

Not just an academic prototype. There are commercial implementations:
http://www.zonith.com/products/zonith-indoor-positioning-module/


Part of your premise was that this sort of relay attack could be
accomplished without the phone holder being aware of it. You could also
mitigate that by having the app trigger an audio alert when an
authentication handshake occurs.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org