Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190213224859.GA7151@amd>
In-Reply-To: <20190213224859.GA7151@amd>
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Thu, 14 Feb 2019 16:27:59 +0100
Message-ID: <CAO1O6sdyJbo0LR9Lak+6yP0FKda4o66+8vwx4fE1fe36z2mDNQ@mail.gmail.com>
Subject: Re: [PATCH] pre-shared passcode: secure pairing for "no keyboard, no
 display" devices
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Bluez mailing list <linux-bluetooth@vger.kernel.org>,
        kernel list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Pavel,

Den tors 14 feb. 2019 kl 14:59 skrev Pavel Machek <pavel@ucw.cz>:
>
> Hi!
>
> Currently, "no keyboard, no display" devices can be paired, but
> pairing is not secure against active attacker.
>
> Can we do better? Not for the first pairing; but for the next ones --
> yes, I believe we can.
>
> BLE device in this case has internal storage, and Linux running
> there. From factory, random 6-digit number is stored in the
> flash. Legitimate user knows the number, and system is manipulated so
> that pairing passkey will be this pre-shared passkey. After pairing,
> user is allowed to change it.
>
> [Or maybe passkey is 000000 from the factory; this is still win for
> the user, as long as he can change the key to something random in a
> secure cave.]
>
> Fortunately, kernel support for this is rather easy; patch is attached
> below.
>
> Does someone see a security issue with proposal above?

Assuming "LE Secure Connections" is used, the protocol is only secure
if the passkey is not reused. A 6 digit passkey means 20 bits. The
protocol is performed in 20 steps, where one bit is compared and
revealed in every step. This means the attacker will know for every
attempt the first bit that is incorrect in the attempted passkey. If
the passkey is reused, the attacker can just try the same passkey with
the incorrect bit flipped. In average it takes 10 attempts to crack
the key and maximum 20 attempts. Hence, a static key doesn't really
add much security compared to Just Works and might give a false sense
of security.

A static key for Legacy Pairing has comparable security as using a
random key. The security is kind of the same as logging in to a
website over unencrypted HTTP, assuming the static key is stored on
the peripheral and the user enters the passkey on the central. In the
case where the passkey is entered by the user on the peripheral
instead of the central, the protocol is completely broken
(https://eprint.iacr.org/2013/309.pdf).

/Emil