Re: [Bluez-devel] RFCOMM service level security testing

[Steven Singer <steven.singer@csr.com>]

Marcel Holtmann wrote:
> do you know any document that explicit requires it? Maybe SIM Access?

Not offhand, but I would have thought it was implicit in the security
model.

Not many systems have to worry about running profiles whilst
simultaneously allowing direct access to HCI.

Of course, even for systems that don't allow access to HCI, they still
have to worry about the other side disabling encryption.

> I heard rumors that encryption costs more CPU and so consumes more
> power. Is this still true with modern chips or can we ignore this?

I'd be surprised if this has ever been true to a significant level.

The encryption engine used in Bluetooth is quite lightweight if
implemented in hardware. I can't imagine that anyone has implemented it
in software (not least because the encryption stream used depends on the
time at which the packet is transmitted - retransmits use a different
obscuring stream).

Compared to the power the rest of the system is taking (most notably,
the radio), the encryption is negligible.

It's reasonable to work on a model that encryption is free. In which
case the question is, is there any reason encryption shouldn't be turned
on as early as possible (as soon as authentication completes)?

> This is a good point, but I think I will explicit have this fine gain
> control. However it is enough to set the *_ENCRYPT flag for example and
> the authentication will be triggered always first.

Strictly speaking, it's impossible to enable encryption at the baseband
level without first having authenticated (though only one side needs to
have initiated authentication).

There's a strong argument, however, for having just one combined flag
that requests both authentication and encryption. Fewer flags means
less complexity.

The problem with having separate flags is that someone might think "oh,
I don't care if anyone snoops on this data, I just want to make sure I
get requests only from trusted devices". In that case they might request
only authentication and not encryption. Unfortunately, this is not
enough to prevent session hijacking.

By having just one flag, you remove the possibility that anyone could
chose an inappropriate setting. They'll just have two options: secure
and insecure.

	- Steven



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************