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

[Marcel Holtmann <marcel@holtmann.org>]

Hi Steven,

> > 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 have to check that, because I can't remember that I read something
like that somewhere. Maybe it is possible that nobody thought about this
before. I only realized that problem when I implemented the security
hooks in the BlueZ core.

> > 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)?

Thanks for this clarification. So automatically dropping the encryption
is not an option that we will support. You need to do this by your own
with a HCI command.

If anyone has measured this for some reason, I like to see the data or
the report with the end result.

> > 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.

I think of following your advice, but still having a *_ENCRYPT and
*_AUTH flag. If one of this flags is set, the authentication and also
the encryption will be requested. But only when the *_ENCRYPT flag is
set, the connection will be dropped when the encryption is disabled.
Does this makes sense or should we simply introduce another flag that is
named for example *_SECURE. I haven't made any decision so far and any
feedback and comments are welcome.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel