Re: Bluetooth cracked further

2005-06-04 Thread Dan Riley
Matt Crawford [EMAIL PROTECTED] writes:
 On Jun 3, 2005, at 11:55, Perry E. Metzger wrote:
  2) They also have a way of forcing pairing to happen, by impersonating
 one of the devices and saying oops! I need to pair again! to the
 other.
 
 Do the devices then pair again without user intervention, re-using the
 PIN that paired them initially?

In the notes for section 5, they say

If the attack is successful, the Bluetooth user will need to enter
the PIN again - so a suspicious user may realize that his
Bluetooth device is under attack and refuse to enter the PIN.

So no, it doesn't re-pair without intervention.

-dan

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Thomas Lakofski
Perry E. Metzger wrote:
 Matt Crawford [EMAIL PROTECTED] writes:
 
On Jun 3, 2005, at 11:55, Perry E. Metzger wrote:

2) They also have a way of forcing pairing to happen, by impersonating
   one of the devices and saying oops! I need to pair again! to the
   other.

Do the devices then pair again without user intervention, re-using the
PIN that paired them initially?
 
 
 That is my understanding. Ugly, isn't it?

The paper addresses countermeasures; it would appear that the original PIN is
not stored for reuse in most (any?) implementations, but that there is an option
to use a PIN every time the devices are connected, which would expose this risk:

6 Countermeasures
 This section details the countermeasures one should consider when using a
Bluetooth device. These countermeasures will reduce the probability of being
subjected to both attacks and the vulnerability to these attacks.

 Since Bluetooth is a wireless technology, it is very difficult to avoid
Bluetooth signals from leaking outside the desired boundaries. Therefore, one
should follow the recommendation in the Bluetooth standard and refrain from
entering the PIN into the Bluetooth device for pairing as much as possible. This
reduces the risk of an attacker eavesdropping on the pairing process and finding
the PIN used.

 Most Bluetooth devices save the link key (Kab) in non-volatile memory for
future use. This way, when the same Bluetooth devices wish to communicate again,
they use the stored link key. However, there is another mode of work, which
requires entering the PIN into both devices every time they wish to communicate,
even if they have already been paired before. This mode gives a false sense of
security! Starting the pairing process every time increases the probability of
an attacker eavesdropping on the messages transferred. We suggest not to use
this mode of work.

 Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers use a 4
digit PIN and supply it with the device. Obviously, customers should demand the
ability to use longer PINs.

-thomas

--
Thomas Lakofski +44 70 9228 8229
'Reality is that which, when you stop believing in it, doesn't go away' --PKD
gpg: 1024D/81FD4B43  2B72 53DB 8104 2041 BDB4  F053 4AE5 01DF 81FD 4B43
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Olle Mulmo


On Jun 4, 2005, at 14:12, Thomas Lakofski wrote:

Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers 
use a 4 digit PIN and supply it with the device. Obviously, customers 
should demand the ability to use longer PINs.


Correction: Most manufacturers hardcode the 4-digit PIN to . It has 
been known for some time that those gadgets need to be paired in an 
Faradayic environment: if I recall correctly, a paper being presented 
on this at the RSA conference ~2001 or so.


The forced re-pairing vulnerability is news to me. It makes me very 
concerned about Bluetooth keyboards...


/O


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-04 Thread Thomas Lakofski
Olle Mulmo wrote:
 On Jun 4, 2005, at 14:12, Thomas Lakofski wrote:

Wrote?  Well, quoted...

 Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers
 use a 4 digit PIN and supply it with the device. Obviously, customers
 should demand the ability to use longer PINs.

 Correction: Most manufacturers hardcode the 4-digit PIN to . It has
 been known for some time that those gadgets need to be paired in an
 Faradayic environment: if I recall correctly, a paper being presented on
 this at the RSA conference ~2001 or so.

For some values of 'most.'  This would cover mice, keyboards and wireless
headsets.  My MS Bluetooth mouse doesn't need any PIN or even encryption to
connect...  I've yet to see a Bluetooth-capable telephone with a fixed PIN; I
would doubt that the number of shipped BT mice, keyboards and headsets exceeds
the number of BT-capable telephones in existence.

 The forced re-pairing vulnerability is news to me. It makes me very
 concerned about Bluetooth keyboards...

Your attacker would need to keep a device live and in the neighbourhood of your
Bluetooth keyboard to perform a mitm attack; I'd be more worried about the
non-Bluetooth wireless keyboards out there.

-thomas

ps, it's a little ironic that a post to a cryptography list has its digital
signature stripped before reaching the list, no?

--
Thomas Lakofski +44 70 9228 8229
'Reality is that which, when you stop believing in it, doesn't go away' --PKD
gpg: 1024D/81FD4B43  2B72 53DB 8104 2041 BDB4  F053 4AE5 01DF 81FD 4B43
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Bluetooth cracked further

2005-06-03 Thread Perry E. Metzger

Cracking the Bluetooth PIN

http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/index.html

Abstract:
  This paper describes the implementation of an attack on the Bluetooth
  security mechanism. Specifically, we describe a passive attack, in
  which an attacker can find the PIN used during the pairing process. We
  then describe the cracking speed we can achieve through three
  optimizations methods. Our fastest optimization employs an algebraic
  representation of a central cryptographic primitive (SAFER+) used in
  Bluetooth. Our results show that a 4-digit PIN can be cracked in less
  than 0.3 sec on an old Pentium III 450MHz computer, and in 0.06 sec on
  a Pentium IV 3Ghz HT computer. 


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-03 Thread Matt Crawford

On Jun 3, 2005, at 11:55, Perry E. Metzger wrote:

2) They also have a way of forcing pairing to happen, by impersonating
   one of the devices and saying oops! I need to pair again! to the
   other.


Do the devices then pair again without user intervention, re-using the 
PIN that paired them initially?


I always imagined I could use a lame PIN if I was far from any 
eavesdroppers...



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-03 Thread Edgar Danielyan
 If you have a pair of bluetooth devices that are paired, best to keep
 them in a faraday cage at all times.

Buy a Bluetooth phone and get a matching colour Faraday cage for FREE! *

* Faraday not included.

...

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Bluetooth cracked further

2005-06-03 Thread Perry E. Metzger

Matt Crawford [EMAIL PROTECTED] writes:
 On Jun 3, 2005, at 11:55, Perry E. Metzger wrote:
 2) They also have a way of forcing pairing to happen, by impersonating
one of the devices and saying oops! I need to pair again! to the
other.

 Do the devices then pair again without user intervention, re-using the
 PIN that paired them initially?

That is my understanding. Ugly, isn't it?

 I always imagined I could use a lame PIN if I was far from any
 eavesdroppers...

Given the nature of this new attack, it probably doesn't matter.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]