From: Marcel Holtmann <marcel@holtmann.org>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: linux-bluetooth <linux-bluetooth@vger.kernel.org>
Subject: Re: Unencrypted keyboard allows password visibility
Date: Sun, 17 Jul 2011 12:58:39 +0200 [thread overview]
Message-ID: <1310900320.21109.115.camel@aeonflux> (raw)
In-Reply-To: <1310842470.4874.35.camel@THOR>
Hi Peter,
> If a keyboard remote device does not initially require encryption during
> initial ACL connection, then passwords (or other initial input) may be
> transmitted unencrypted.
>
> The main problem is that the input server does not force link encryption
> until *after* both the ctrl and intr l2cap channels are connected. This
> will allow the remote device to begin transmitting unencrypted hid input
> reports -- which is often a password!
are you sure keyboards transmit data if only one channel is connected.
If I remember this correctly then they should not. Only when both
channels are setup, the HID connection is complete. And only then
encryption should be required.
> Inquiring minds can review hidp_add_connection() in input/device.c for
> details.
>
> However, before I submit a patch, is the device class from the sdp/hid
> record preferable to the l2cap socket device class (via btio)?
Anyhow, in theory this is still all a race condition. It would be better
to use our DEFER_ACCEPT support in the kernel and allow in between that
phase to set the encryption requirement on that socket. And then have
the kernel ensure a secured link before allowing any L2CAP packets
coming in. Something similar to what is ensured with Security Modem 4
for non-SDP channels.
Regards
Marcel
next prev parent reply other threads:[~2011-07-17 10:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-16 18:54 Unencrypted keyboard allows password visibility Peter Hurley
2011-07-17 10:58 ` Marcel Holtmann [this message]
2011-07-17 15:23 ` Peter Hurley
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=1310900320.21109.115.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.