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> <CAO1O6sdyJbo0LR9Lak+6yP0FKda4o66+8vwx4fE1fe36z2mDNQ@mail.gmail.com>
 <20190215114622.GA32198@amd>
In-Reply-To: <20190215114622.GA32198@amd>
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Fri, 15 Feb 2019 13:21:45 +0100
Message-ID: <CAO1O6sfLuUtOJdxFkRxck_eLmwtSQ3aU6Rub_hrxaJ5dmWr_HA@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,
Den fre 15 feb. 2019 kl 12:46 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.
>
> Thanks a lot for quick reply. And no, that is not good.
>
> Just Works basically means that there's no security at all, anyone
> within range can connect when owner is not around, and do whatever
> they want.
>
> Is there some common way this is solved?
>
> We do have pre-shared passkey, if only 20 bits. If we set
> passkey = sha( pre-shared passkey + pairing_attempt++ ), would we get
> some kind of meaningful security? Perhaps with limiting pairing
> attempt to say 10 a day?

I see two issues with that approach. First, the user needs to know the
correct counter of pairing_attempt (how?) and perform the sha
calculation and map that to a passkey. Second, if you eavesdrop a
pairing attempt that succeeds, you can just bruteforce sha over all
possible pre-shared passkeys (1 million if you have 6 digits) times
the number of different pairing_attempt counters you want to test, and
match that with the recorded pairing messages. That shouldn't take
more than a few seconds on a normal PC.

What people really do that wants proper security over BLE when they
need to use static passkeys, is using a PAKE algorithm in the
application layer to establish a session key, and then use some AEAD
cipher with that session key also in the application layer (or
potentially start BLE encryption using that session key as LTK, but I
haven't seen that). Unencrypted BLE is just used then as a transport
layer.

/Emil