[Freedombox-discuss] Tap-to-share PGP key exchange

[Nick Daly]

(sorry to toppost, have too much to do to spend time reformatting the
email through gmail)

The really important point here is the threatmodel.  A bluetooth
pairing offers a 1 in 10^6 bruteforce chance.  A PGP key offers a 1 in
2^1024 (or smaller) bruteforce chance. PGP keys are built for long
term security against extended bruteforce attacks.  The
one-in-a-million bruteforce chance might be appropriate for bluetooth
parings given that the key is valid only for a matter of minutes (and
devices are listening only for a number of seconds before locking the
transfer to a specific device ID).

You could elaborate the model and solution more if you were really
worried.  For Secure Simple Paring, each device would transmit its
device ID along with the bluetooth key.  If any device sees another
device send its own ID before the lock is confirmed, it sends a panic
signal and the paring attempt is canceled.  Worst case scenario with
MITM attack: no paring is possible.  Much better than an inappropriate
paring.

Nick

On Tue, Oct 4, 2011 at 3:45 PM, Timur Mehrvarz
<timur.mehrvarz at googlemail.com> wrote:
> On 04.10.2011 18:38, Daniel Kahn Gillmor wrote:
>> On 10/04/2011 11:56 AM, Timur Mehrvarz wrote:
>>
>>> I really wish we could get to a point where we can trust the
>>> wireless connection, reducing the number of steps needed for PGP
>>> based "friedning", making the process more acceptable for
>>> 'regular people'.
>>
>> i agree that it would be nice if this were possible.  I'm just not
>> sure how we'd get there.
>>
>
> But we may be there already.
>
> Excerpts from "BLUETOOTH SPECIFICATION Version 3.0 + HS":
>
> --- quote ---
>
> Secure Simple Pairing has two security goals: protection against
> passive eavesdropping and protection against man-in-the-middle (MITM)
> attacks (active eavesdropping).
>
> Secure Simple Pairing uses Elliptic Curve Diffie Hellman (ECDH) public
> key cryptography as a means to thwart passive eavesdropping attacks.
>
> Secure Simple Pairing has approximately 95 bits of entropy using the
> FIPS approved P192 elliptic curve which is at least as good as the
> entropy in Bluetooth Core Specification 2.0 + EDR and earlier using a
> 16 character, alphanumeric, case sensitive PIN. Secure Simple Pairing,
> therefore, exceeds the security requirements of the Bluetooth SIM
> Access Profile (SAP) which is the profile with the most stringent
> security requirements. ECDH cryptography was selected over standard
> Diffie Hellman (often referred to as DH76) since it is computationally
> less complex and less likely to exceed the low computational capacity
> in common Bluetooth Controllers. [...]
>
> A man-in-the-middle (MITM) attack occurs when a user wants to connect
> two devices but instead of connecting directly with each other they
> unknowingly connect to a third (attacking) device that plays the role
> of the device they are attempting to pair with. The third device then
> relays information between the two devices giving the illusion that
> they are directly connected. The attacking device may even eavesdrop
> on communication between the two devices (known as active
> eavesdropping) and is able to insert and modify information on the
> connection. In this type of attack, all of the information exchanged
> between the two devices are compromised and the attacker may inject
> commands and information into each of the devices thus potentially
> damaging the function of the devices.[...]
>
> To prevent MITM attacks, Secure Simple Pairing offers two user
> assisted numeric methods: numerical comparison or passkey entry. [...]
>
> Secure Simple Pairing protects the user from MITM attacks with a goal
> of offering a 1 in 1,000,000 chance that a MITM could mount a
> successful attack. The strength of the MITM protections was selected
> to minimize the user impact by using a six digit number for numerical
> comparison and Passkey entry. This level of MITM protection was
> selected since, in most cases, users can be alerted to the potential
> presence of a MITM attacker when the connection process fails as a
> result of a failed MITM attack. While most users feel that provided
> that they have not compromised their passkey, a 4-digit key is
> sufficient for authentication (i.e. bank card PIN codes), the use of
> six digits allows Secure Simple Pairing to be FIPS compliant and this
> was deemed to have little perceivable usability impact.
>
> The Numeric Comparison association model is designed for scenarios
> where both devices are capable of displaying a six digit number and
> both are capable of having the user enter "yes" or "no". A good
> example of this model is the cell phone / PC scenario. The user is
> shown a six digit number (from "000000" to "999999") on both displays
> and then asked whether the numbers are the same on both devices. If
> "yes" is entered on both devices, the pairing is successful. The
> numeric comparison serves two purposes. First, since many devices do
> not have unique names, it provides confirmation to the user that the
> correct devices are connected with each other. Second, the numeric
> comparison provides protection against MITM attacks. Note that there
> is a significant difference from a cryptographic point of view between
> Numeric Comparison and the PIN entry model used by Bluetooth Core
> Specification and earlier versions. In the Numeric Comparison
> association model, the six digit number is an artifact of the security
> algorithm and not an input to it, as is the case in the Bluetooth
> security model. Knowing the displayed number is of no benefit in
> decrypting the encoded data exchanged between the two devices.
>
> --- unquote ---
>
> Is there any proof out there this doesn't work as specified?
>
> Secure Simple Pairing with six digit passkey as implemented under
> Android (screenshot 4): http://timur.mobi/anymime/
>
> Timur
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>