Security level of connections initiated by applications. about web-bluetooth HOT 11 CLOSED

A device will set security requirements for each and every characteristic it has, at a minimum I would argue the Browser shall ensure all connections are encrypted and so STK's should be created. GATT defines how the device shall respond if an attempt is made to read or write a characteristic is made but the security/authentication requirements have not been met.

from web-bluetooth.

I agree with this. I guess we should mention in the API specification that outgoing connections MUST have at least medium security (in GAP terms).

from web-bluetooth.

We need to specify the security requirements for both BR/EDR and LE since BT4.1/3.C (GAP) defines them independently. For BR/EDR, requiring Security Mode 4 with a Security Level of at least 2 seems plausible. What devices will we exclude by doing that?

For LE, it looks like the equivalent requirement is Security Mode 1 with a Security Level of at least 2 ("Unauthenticated pairing with encryption" or "Authenticated pairing with encryption"). That rules out Mode 2/Level 2, "Authenticated pairing with data signing" without encryption. What sorts of devices does this choice exclude?

I think it does make sense to put these requirements in the spec until someone presents an argument for a lower security level.

Given these minimum requirements, it probably also makes sense to let a site request authenticated pairing ("MITM protection"?), probably as an options dictionary on requestDevice().

from web-bluetooth.

I guess this depends on OS configuration. Out of curiosity, can Browsers really force any Security Level?

from web-bluetooth.

That's a very good point. I don't see any Mac API to let the Central require encryption or authentication, so the best we can say is SHOULD, not MUST. Windows appears to let us set security independently for each Characteristic with GattCharacteristic.ProtectionLevel, and we can probably make ChromeOS or FirefoxOS do it by, in the worst case, messing with the kernel.

But given that a web programmer won't be able to rely on encryption (let alone MITM protection), maybe we shouldn't even mention the SHOULD?

from web-bluetooth.

From the same Windows API page that you linked:

"Windows will negotiate the maximum security possible with the device as part of the pairing process, and specifying a lower level of security won’t degrade the existing security level."

So the link itself always uses maximum security and this seems to be enforced by the OS. On Chrome OS we do a similar thing where we always enforce a GAP security level of medium or higher. So maybe the API spec should just encourage UAs to do the same? Or perhaps use MUST for at least encrypted communication w/o MITM but the UA can choose to enforce a higher level? Note that if the peripheral requires MITM, then the security level must be raised regardless.

A note about per-characteristic security: access restrictions imposed on a characteristic/descriptor value are at a higher level than the Attribute protocol and L2CAP and is handled by the GATT server implementation usually. Since we're currently proposing a central-focused API, specifying a per-characteristic permission is something that we can (i.e. will have to) worry about later for the peripheral API.

from web-bluetooth.

That's the maximum security supported by the device ... which I guess if we require at least BT2.1 is Medium, as you say (3.C.5.2.2.8). It probably makes sense to include a non-normative section explaining this in the Security and privacy considerations section, but I don't think there's anything normative to say about it, including that UAs are allowed to connect at a higher security level than BT requires.

For LE, it looks like "No security (No authentication and no encryption)" is allowed by BT, so Windows might connect to certain devices at that level. I don't even see a way to ask Win or Mac what security level they're connected in. :-(

For per-characteristic security, a comment in the HeartRateService.cpp example says:

// While encryption is not required by all devices, if encryption is supported by the device,
// it can be enabled by setting the ProtectionLevel property of the Characteristic object.
// All subsequent operations on the characteristic will work over an encrypted link.

That appears to be even for Central operation (since the HeartRateService example isn't defining a peripheral), although I haven't tested it out. MacOS does only provide this switch when defining a Peripheral.

from web-bluetooth.

I'm not exactly sure how the Windows LE stack works really. There isn't a way that I know of for an application to have per-characteristic LE connections. Maybe Windows creates a new connection at different security levels for characteristic read/writes? Or maybe they do this so that an application can request higher level security if a characteristic value read/write is rejected due to a permissions set at the remote GATT server level, at which point ALL operations work at that higher security level?

In short, I believe this is the problem that they are addressing: permission levels that are specified by a peripheral for access to individual GATT characteristics is done way above the L2CAP layer. Hence, if a central creates a connection that doesn't meet the access permission requirements of a characteristic, this Windows API allows the central to raise the security level.

I'm not sure what sort of API our Web spec should provide for this. Note that the ATT protocol doesn't have a concept of an "Attribute Permission" at the PDU level: i.e. it defines possible attribute permissions but doesn't provide a way to obtain what that permission level is other than making a read/write request to that attribute and using the received error response to determine the access permissions.

So, perhaps, if an application calls readValue or writeValue, and the operation fails with an ATT error response such as "ERROR_AUTHENTICATION", "ERROR_AUTHORIZATION", "ERROR_INSUFFICIENT_ENCRYPTION", etc. then we allow the UA to automatically try and raise the security level? This is sort of what we try to do on ChromeOS.

I wonder what Mac does in this case.

from web-bluetooth.

Between two physical devices there shall be one and only one LE-ACL connection.

from web-bluetooth.

Between two physical devices there shall be one and only one LE-ACL connection.

Never suggested otherwise :)

from web-bluetooth.

I suspect the Windows Central-side per-characteristic permissions do work by upgrading the whole connection when any in-use characteristic needs more security. I think we do need to allow/encourage the UA to handle an ERROR_AUTHENTICATION, etc. by upgrading the connection and retrying. I think I found a note that Mac also does this automatically, but I'm having trouble re-finding the link.

I'm inclined to avoid any APIs or requirements here until someone documents a way to implement them on all platforms.

from web-bluetooth.