Hi Folks,
I released patch-2.6.9-mh3 some minutes ago and it contains the first
experimental version of the service level security implementation for
the RFCOMM layer.
The libs CVS is also updated to add the specific defines for using it
and rctest got some extra paramters for it, but it seems that the CVS
service for anonymous access from Sourceforge is broken and so most of
you won't get these modification. However this is not a big problem,
because you can use L2CAP_LM, L2CAP_LM_AUTH etc. for it. The values
behind these defines are identical and so this should work at least for
testing this new feature.
Please test this and send reports back to the mailing list.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Steve,
> > does anyone tested this on a SMP system, a 64 bit box or big endian
> > machine?
>
> I have an old dual-celeron at home. I'll try and make some time to
> re-run the Java tests on it over the next few days. It will probably be
> the weekend though.
the current version is not SMP safe. When using a SMP preempt kernel on
an UP machine with debugging I get this log:
Debug: sleeping function called from invalid context at net/core/sock.c:1207
in_atomic():1, irqs_disabled():0
[<c0116a68>] __might_sleep+0xb2/0xd3
[<c0241cca>] lock_sock+0x21/0x55
[<e1421dc3>] l2cap_sock_sendmsg+0x5e/0x3bb [l2cap]
[<c0113359>] try_to_wake_up+0x1e1/0x26f
[<c023e1c2>] sock_sendmsg+0x11a/0x11c
[<c0113405>] wake_up_process+0x1e/0x22
[<e1422f93>] l2cap_recv_frame+0xc2/0xd10 [l2cap]
[<c012d1d6>] autoremove_wake_function+0x0/0x57
[<c020e872>] dma_pool_alloc+0x11f/0x16a
[<c023e20a>] kernel_sendmsg+0x46/0x55
[<e1434b36>] rfcomm_send_frame+0x55/0x65 [rfcomm]
[<e1434c1e>] rfcomm_send_ua+0x6b/0x73 [rfcomm]
[<e1435647>] rfcomm_dlc_accept+0x25/0x77 [rfcomm]
[<e1436875>] rfcomm_auth_cfm+0x7a/0x91 [rfcomm]
[<e0a8ab40>] hci_event_packet+0xa9e/0x1003 [bluetooth]
[<c0114cf8>] __wake_up_common+0x3f/0x5e
[<c0114d57>] __wake_up+0x40/0x56
[<c024197f>] sock_def_readable+0x88/0x8a
[<c0243be5>] skb_queue_tail+0x20/0x4b
[<e0a8b38f>] hci_send_to_sock+0x16b/0x29a [bluetooth]
[<e0a8897f>] hci_rx_task+0x1a1/0x293 [bluetooth]
[<c011e1f4>] tasklet_action+0x65/0xae
[<c011df43>] __do_softirq+0xb7/0xc6
[<c011df7f>] do_softirq+0x2d/0x2f
[<c0134b31>] irq_exit+0x3a/0x3c
[<c010652e>] do_IRQ+0x1e/0x24
[<c0104a9a>] common_interrupt+0x1a/0x20
[<c010203e>] default_idle+0x0/0x2c
[<c0102067>] default_idle+0x29/0x2c
[<c01020dc>] cpu_idle+0x3f/0x58
[<c031c89d>] start_kernel+0x151/0x16a
[<c031c336>] unknown_bootoption+0x0/0x1ab
And this means that I have to queue the UA or DM response and I can't
switch into BT_CONNECTED state at that point.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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.
http://www.mimesweeper.com
**********************************************************************
Hi Steven,
> > * If encryption on a link is switched off at the HCI level, _all_ of the
> > connections (L2CAP and RFComm) which required it should be closed
> > shouldn't they?
>
> Fair enough.
do you know any document that explicit requires it? Maybe SIM Access?
Basically I think it is a good idea and for the RFCOMM part I must check
if I have to send DISC or DM. The L2CAP part must be fixed, but the new
HCI callback stuff should make this very easy. However it needs more
core changes for a better integration.
> > * Conversely, encryption should be automatically turned off on a link
> > when the last connection which required encryption is closed.
>
> I don't see any strong reason for this. Encryption is free, once it's
> on there's no advantage in switching it off (unless you want to run
> an air sniffer, in which case you can turn it off at HCI).
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?
> > * Owners of a connection should be able to indicate that they're no
> > longer interested in encryption by an ioctl on the L2CAP or RFComm
> > socket.
> >
> > * Connections which were created without the encryption requirement
> > should be able to ask for it by a similar ioctl.
>
> This runs counter to the Bluetooth security model. Either a service
> allows only trusted devices to connect or it allows any device. Are
> there any situations where allowing untrusted devices to connect and
> then become trusted later is superior to having two separate services,
> one secure and one insecure. For example, rather than having an OBEX
> service that doesn't require trust to accept a v-card but will initiate
> a security procedure when an application/octet-stream is sent, instead
> have two OBEX services, one for untrusted devices to send v-cards and
> one for trusted devices to send anything.
>
> Also, asking for authentication during a service activity may confuse
> other implementations. If a device is displaying an animation of a
> transfer in progress, how will it handle suddenly having to display
> a Bluetooth passphrase entry screen?
>
> Applying security at the start of a service is less prone to error
> than working out when, during a session, security needs to be enabled.
We really need to investigate this and see how devices react. I had some
problems with activating encryption on HID after I had established the
control and interrupts channels.
> > I imagine this behaviour would be required only very rarely but it seems
> > the most intuitive to me. What do you think?
>
> Can I add to this discussion, that any non-encrypted link must not be
> treated as trusted. As well as snooping, a sufficiently determined
> attacker can hijack a non-encrypted link. If they wait for
> authentication to complete then take over the link they will be able to
> insert their own packets and inherit the link's trust. Using encryption
> also prevents man-in-the-middle attacks where the attacker uses each
> device as an oracle to calculate the correct response to the
> authentication challenge. The encryption key is derived, in part, from
> information generated whilst calculating the response but which isn't
> transmitted over the air.
>
> Encryption should be seen as an integral part of authentication.
> Either a link is authenticated and encrypted or it's unauthenticated.
>
> Giving services a fine degree of control over encryption settings
> just leaves more possibilities for incorrect, and hence insecure,
> implementations.
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Stephen Crane wrote:
> On Wed, 2004-11-03 at 15:37, Marcel Holtmann wrote:
>> Another question is what should we do when the encryption on a link with
>> RFCOMM_ENCRYPT is switched off? At the moment L2CAP keeps works, but in
>> the RFCOMM layer I drop the connection by sending DM.
>
> Yeah I thought I saw something like this happen. I don't think it is
> correct behaviour. My reasoning would go something like this:
>
> * If encryption on a link is switched off at the HCI level, _all_ of the
> connections (L2CAP and RFComm) which required it should be closed
> shouldn't they?
Fair enough.
> * Conversely, encryption should be automatically turned off on a link
> when the last connection which required encryption is closed.
I don't see any strong reason for this. Encryption is free, once it's
on there's no advantage in switching it off (unless you want to run
an air sniffer, in which case you can turn it off at HCI).
> * Owners of a connection should be able to indicate that they're no
> longer interested in encryption by an ioctl on the L2CAP or RFComm
> socket.
>
> * Connections which were created without the encryption requirement
> should be able to ask for it by a similar ioctl.
This runs counter to the Bluetooth security model. Either a service
allows only trusted devices to connect or it allows any device. Are
there any situations where allowing untrusted devices to connect and
then become trusted later is superior to having two separate services,
one secure and one insecure. For example, rather than having an OBEX
service that doesn't require trust to accept a v-card but will initiate
a security procedure when an application/octet-stream is sent, instead
have two OBEX services, one for untrusted devices to send v-cards and
one for trusted devices to send anything.
Also, asking for authentication during a service activity may confuse
other implementations. If a device is displaying an animation of a
transfer in progress, how will it handle suddenly having to display
a Bluetooth passphrase entry screen?
Applying security at the start of a service is less prone to error
than working out when, during a session, security needs to be enabled.
> I imagine this behaviour would be required only very rarely but it seems
> the most intuitive to me. What do you think?
Can I add to this discussion, that any non-encrypted link must not be
treated as trusted. As well as snooping, a sufficiently determined
attacker can hijack a non-encrypted link. If they wait for
authentication to complete then take over the link they will be able to
insert their own packets and inherit the link's trust. Using encryption
also prevents man-in-the-middle attacks where the attacker uses each
device as an oracle to calculate the correct response to the
authentication challenge. The encryption key is derived, in part, from
information generated whilst calculating the response but which isn't
transmitted over the air.
Encryption should be seen as an integral part of authentication.
Either a link is authenticated and encrypted or it's unauthenticated.
Giving services a fine degree of control over encryption settings
just leaves more possibilities for incorrect, and hence insecure,
implementations.
- 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.
http://www.mimesweeper.com
**********************************************************************
On Wed, 2004-11-03 at 16:08, Marcel Holtmann wrote:
> does anyone tested this on a SMP system, a 64 bit box or big endian
> machine?
I have an old dual-celeron at home. I'll try and make some time to
re-run the Java tests on it over the next few days. It will probably be
the weekend though.
> > > Another question is what should we do when the encryption on a link with
> > > RFCOMM_ENCRYPT is switched off? At the moment L2CAP keeps works, but in
> > > the RFCOMM layer I drop the connection by sending DM.
> >
> > Yeah I thought I saw something like this happen. I don't think it is
> > correct behaviour. My reasoning would go something like this:
> >
> > * If encryption on a link is switched off at the HCI level, _all_ of the
> > connections (L2CAP and RFComm) which required it should be closed
> > shouldn't they?
> >
> > * Conversely, encryption should be automatically turned off on a link
> > when the last connection which required encryption is closed.
> >
> > * Owners of a connection should be able to indicate that they're no
> > longer interested in encryption by an ioctl on the L2CAP or RFComm
> > socket.
> >
> > * Connections which were created without the encryption requirement
> > should be able to ask for it by a similar ioctl.
> >
> > I imagine this behaviour would be required only very rarely but it seems
> > the most intuitive to me. What do you think?
>
> Actually I have no real meaning about it a the moment. There are pros
> and cons and I like to follow some written specification or erratum. Is
> there something that tells us exactly what to do in these cases?
There is something related to this on p50 of the JSR-82 spec (and, not
coincidentally, in our implementation of it):
"[...] withdrawing a request for encryption does not necessarity mean
that encryption is turned off. If other connections to this same device
need encryption, then the data link that underlies all of the
connections might continue to be encrypted, depending on the policies
used in the BCC for this device."
Regards,
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Steve,
> > thanks for testing and what do you think, should I put this feature into
> > the next stable kernel?
>
> Yes: definitely!
does anyone tested this on a SMP system, a 64 bit box or big endian
machine?
> > Another question is what should we do when the encryption on a link with
> > RFCOMM_ENCRYPT is switched off? At the moment L2CAP keeps works, but in
> > the RFCOMM layer I drop the connection by sending DM.
>
> Yeah I thought I saw something like this happen. I don't think it is
> correct behaviour. My reasoning would go something like this:
>
> * If encryption on a link is switched off at the HCI level, _all_ of the
> connections (L2CAP and RFComm) which required it should be closed
> shouldn't they?
>
> * Conversely, encryption should be automatically turned off on a link
> when the last connection which required encryption is closed.
>
> * Owners of a connection should be able to indicate that they're no
> longer interested in encryption by an ioctl on the L2CAP or RFComm
> socket.
>
> * Connections which were created without the encryption requirement
> should be able to ask for it by a similar ioctl.
>
> I imagine this behaviour would be required only very rarely but it seems
> the most intuitive to me. What do you think?
Actually I have no real meaning about it a the moment. There are pros
and cons and I like to follow some written specification or erratum. Is
there something that tells us exactly what to do in these cases?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Wed, 2004-11-03 at 15:37, Marcel Holtmann wrote:
> thanks for testing and what do you think, should I put this feature into
> the next stable kernel?
Yes: definitely!
> Another question is what should we do when the encryption on a link with
> RFCOMM_ENCRYPT is switched off? At the moment L2CAP keeps works, but in
> the RFCOMM layer I drop the connection by sending DM.
Yeah I thought I saw something like this happen. I don't think it is
correct behaviour. My reasoning would go something like this:
* If encryption on a link is switched off at the HCI level, _all_ of the
connections (L2CAP and RFComm) which required it should be closed
shouldn't they?
* Conversely, encryption should be automatically turned off on a link
when the last connection which required encryption is closed.
* Owners of a connection should be able to indicate that they're no
longer interested in encryption by an ioctl on the L2CAP or RFComm
socket.
* Connections which were created without the encryption requirement
should be able to ask for it by a similar ioctl.
I imagine this behaviour would be required only very rarely but it seems
the most intuitive to me. What do you think?
Regards,
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Steve,
> I've run our basic RFComm server-side security tests against 2.6.9-mh3
> and they all seem to pass (previously they'd all failed of course). Nice
> work!
thanks for testing and what do you think, should I put this feature into
the next stable kernel?
Another question is what should we do when the encryption on a link with
RFCOMM_ENCRYPT is switched off? At the moment L2CAP keeps works, but in
the RFCOMM layer I drop the connection by sending DM.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
I've run our basic RFComm server-side security tests against 2.6.9-mh3
and they all seem to pass (previously they'd all failed of course). Nice
work!
Regards,
Steve
On Tue, 2004-11-02 at 22:03, Marcel Holtmann wrote:
> Hi Folks,
>
> > I released patch-2.6.9-mh3 some minutes ago and it contains the first
> > experimental version of the service level security implementation for
> > the RFCOMM layer.
> >
> > The libs CVS is also updated to add the specific defines for using it
> > and rctest got some extra paramters for it, but it seems that the CVS
> > service for anonymous access from Sourceforge is broken and so most of
> > you won't get these modification. However this is not a big problem,
> > because you can use L2CAP_LM, L2CAP_LM_AUTH etc. for it. The values
> > behind these defines are identical and so this should work at least for
> > testing this new feature.
> >
> > Please test this and send reports back to the mailing list.
>
> what's up? Has nobody tested this new feature so far? The Sourceforge
> CVS is now back in sync and rctest has all needed options.
>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Folks,
> I released patch-2.6.9-mh3 some minutes ago and it contains the first
> experimental version of the service level security implementation for
> the RFCOMM layer.
>
> The libs CVS is also updated to add the specific defines for using it
> and rctest got some extra paramters for it, but it seems that the CVS
> service for anonymous access from Sourceforge is broken and so most of
> you won't get these modification. However this is not a big problem,
> because you can use L2CAP_LM, L2CAP_LM_AUTH etc. for it. The values
> behind these defines are identical and so this should work at least for
> testing this new feature.
>
> Please test this and send reports back to the mailing list.
what's up? Has nobody tested this new feature so far? The Sourceforge
CVS is now back in sync and rctest has all needed options.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel