public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Emil Lenngren <emil.lenngren@gmail.com>
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>
Subject: Re: [PATCH] pre-shared passcode: secure pairing for "no keyboard, no display" devices
Date: Fri, 15 Feb 2019 12:46:22 +0100	[thread overview]
Message-ID: <20190215114622.GA32198@amd> (raw)
In-Reply-To: <CAO1O6sdyJbo0LR9Lak+6yP0FKda4o66+8vwx4fE1fe36z2mDNQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

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?

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2019-02-15 11:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 22:48 [PATCH] pre-shared passcode: secure pairing for "no keyboard, no display" devices Pavel Machek
2019-02-14 15:27 ` Emil Lenngren
2019-02-15 11:46   ` Pavel Machek [this message]
2019-02-15 12:21     ` Emil Lenngren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190215114622.GA32198@amd \
    --to=pavel@ucw.cz \
    --cc=emil.lenngren@gmail.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox