As I know, in BLE Secure-Connections Only (SCO) mode, all incoming and outgoing traffic between two paired devices is both authenticated and encrypted. However, BLE also allows to assign individual access permissions to attributes.
Thus, I am wondering whether the BLE specification allows the existence of attributes that neither require authentication nor encryption if two devices are communicating in SCO mode. To give a concrete example: Can device A have an attribute that does not require security and can device B access that attribute without security?
Note that the Secure Connections Only mode is just a high-level "concept" in GAP that doesn't really exist on the ATT/GATT protocol level.
This is all in the spec there is to say about it (Bluetooth Core specification v5.3, Vol 3 Part C (GAP)):
10.2.4 Secure Connections Only mode
A device may be in a Secure Connections Only mode. When in Secure Connections Only mode only security mode 1 level 4 shall be used except for services that only require security mode 1 level 1.
The device shall only accept new outgoing and incoming service level connections for services that require Security Mode 1, Level 4 when the remote device supports LE Secure Connections and authenticated pairing is used.
Mode 1 level 1 means unencrypted, unauthenticated. Mode 1 level 4 means that LE Secure Connections are used with authenticated pairing, i.e. not "LESC Just Works".
So to claim that your device is in SCO mode, you can have a mix of services that don't require any encryption at all and services that only allow to be used when authenticated LESC is used. The services that don't require any encryption can be used at anytime, both when the link is encrypted and when it is unencrypted. The other services can only be used when the connection is encrypted with authenticated LESC.
If I interpret it correctly, you can therefore not have a GATT service with multiple characteristics such that one characteristic is accessable without encryption and one other characteristic is only accessable with encryption. In that case you need to split it up into two services, one without encryption requirements and one with authenticated LESC as requirement.
Anyway, "SCO mode" is just abstract terminology that doesn't have any implications in practice except that it categorises service structures. Basically what you can do with it is to print a label on your product "certified to support SCO mode". It can also be useful as a flag in Bluetooth stacks you can set that validates that the local GATT db fulfills the requirements for SCO.
Related
Is there a way in iOS or Android to set up a Bluetooth passkey passcode whenever another device wants to connect to my device via Bluetooth?
My application involves a BLE client connecting to a BLE server and the two devices will transmit data between each other. However, the data transmitted will be very sensitive security-wise. So beyond the standard encryption my goal is to not initiate data transmission until both devices have authenticated each other (e.g., with a passkey).
It seems like a Bluetooth passkey is something set up by the device manufacturer and not something able to be configured by the user. If so and there is no passkey pairing, would an acceptable alternative be to require a passkey to be exchanged (after the devices are paired) before the devices can transmit any sensitive data?
On a Android phone, assuming the phone is GATT server (which provides data for a client device to read), you can safeguard that data held in a characteristic by setting its read permission to PERMISSION_READ_ENCRYPTED_MITM .
For example, when you create a characteristic to be registered with the Bluetooth stack in Android, you do
BluetoothGattCharacteristic characteristic = new BluetoothGattCharacteristic(YOUR_UUID, BluetoothGattCharacteristic.PROPERTY_READ, BluetoothGattCharacteristic.PERMISSION_READ_ENCRYPTED_MITM)
In this way, anyone who wants to read the characteristic needs to create a secure bonding with your phone first, either by entering a passcode or compare two numerical values. The exact way for pairing is up to the Bluetooth stacks of both devices to negotiate (based on available IO on the client).
On the other hand, if the data you want to access is stored in a third remote device, and you don't need authentication (bonding/pairing) to read from it, and you cant access the firmware. Then you can not enforce secure transmission unilaterally from your phone.
I am investigating the types of security available in Bluetooth Low Energy (BLE) related to GATT. More specifically, what kind of operations are done when using gatttool with different security levels specified (low, med, high)? My understanding is that the Security Manager in BLE supports 4 different security properties:
no pairing
pairing with an association model that doesn't support man-in-the-middle (MitM) protections (JustWorks)
pairing with MitM protections (passkey entry, numeric comparison, OOB)
LE Secure Connections pairing.
Are these security properties related to the security levels specified with gatttool or is there some other security feature I missed while reading the Bluetooth Specification?
Edit: I would like to extend my question in order to clarify the issue. How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
You are correct but you forget one main threat in BLE communication. Here are the three basic threats :
Man In The Middle (MITM) :
A MITM requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel
Eavesdropping :
Passive Eavesdropping is secretly listening (by using a sniffing device) to the private communication of others without consent
Privacy/Identity tracking :
Since most of the Bluetooth LE advertisement and data packets have the source addresses of the devices that are sending the data, third-party devices could associate these addresses to the identity of a user and track the user by that address
The quotes come from developer.bluetooth.org.
You already mentioned the protections against MitM and Eavesdropping, however there is still the problem of identity tracking.
The protection against identity tracking is to use a MAC address that cannot be linked to the same device through time, i.e. a MAC address that changes (typically every 15 minutes). There are four types of MAC address :
Public address : This address is unencrypted and contains your company unique ID and your device ID. It's unsafe since it does not change through time.
Random static address : This address is random (and known as random thanks to flags inside) and unencrypted. Once it does change, you loose the ability to reconnect with the devices that already knows you, you've got to restart the connection from scratch.
Random resolvable private address : This address can be resolved by the devices that know its IRK, a shared secret between the devices. As for the static random address it changes often but is always resolvable. It's the most common option since it preserves privacy and allow to restore a connection.
Random non-resolvable private address : This address cannot be resolved. The Core Spec doesn't say that much about it and it seems not to be very common. The difference with the static address is that it is not stored since it's a private address (i.e. a device doesn't expect to be able to restore a connection with a private address device).
This is explained in BLE Core Spec 4.2 Vol. 3 Part C 15.1.1 Bluetooth Device Address Types.
Concerning the security level, I don't know gatttool but I will assume it's somehow similar to nRF Connect/Master Control Panel or LightBlue. What you see here is probably the security level associated with each attribute. There are four security levels and they can be different for each attribute :
Mode 1 Level 1 :
No encryption required. The attribute is accessible on a plain-text, non-encrypted connection.
Mode 1 Level 2 :
Unauthenticated encryption required. The connection must be encrypted to access this attribute, but the encryption keys do not need to be authenticated (although they can be).
Mode 1 Level 3 :
Authenticated encryption required. The connection must be encrypted with an authenticated key to access this attribute.
Mode 1 Level 4 :
Authenticated LE Secure Connections pairing with encryption. The connection must be encrypted using the Secure Connection Pairing, which was introduced in Bluetooth LE since version 4.2.
The definitions of modes 1 level 1-3 come from 'Getting Started with Bluetooth Low Energy' by Robert Davidson, Akiba, Carles Cufi, Kevin Townsend.
The device can also be in a mode called Secure Connection Only in which all its services, except the one in Mode 1 Level 1, can only be accessed in Mode 1 Level 4.
How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
During the pairing feature exchange stage, if the Secure Connections (SC) flag is set in the Pairing Request and Pairing Response PDUs, then LE SC is used. It indicates that both devices support LE SC and agree to use it.
If LE SC is used, the logs will show "Pairing Public Key" and the "Pairing DHKey Check" PDUs being exchanged. These are specific to LE SC.
Yes it's correct but you should note that their are still exists security mode,LE security mode 1 and LE security mode 2, which is combined by different security levels. And before Bluetooth 4.2, LE is not secure i.e. you can sniffer the encrypt key at the just beginning of the LE connection.
As we all know, HTTPS is a way to protect against session hijacking.
Suppose this isn't an option for some application. Further suppose, users connect to the web-application using a strongly encrypted (WPA2) wifi network.
Fact: WPA2 protects against third parties, which didn't connect correctly to the wifi network.
But does WPA2 additionally protected each legitimate user against each other legitimate user? Does each legitimate user has a securely isolated channel to the wifi router?
Or does the wifi router works more like a hub: If the wifi router needs to send data to a wifi client, it broadcasts it to all clients - so that each client can read the data?
Speaking of web application programming: Do we need to use HTTPS in a
WPA2 protected wifi network to protect each wifi client against each
other wifi client?
In Wi-Fi, as the transmission medium is the air, every STA could intercept data from others STA. So, for this point, you can compare a Wi-Fi network to a hub.
In fact, the 802.11 stack take care of the PHY and the MAC/LLC layers.
Moreover, the WPA/WPA2 encryption is just here to protect foreign STA to read your Wi-Fi network frames.
It's very easy to test, use wireshark with two STAs on the same AP. You should be able to see frames form the other STA.
So if you want to protect a web application on a network which use Wi-Fi (and/or hub but not only), the use of HTTPS is strongly recommended.
I understand that PCI compliance affects not just storage of card details but does it also affect transmission. E.g. if I simply want to collect a card number and transmit it over https does this require PCI compliance steps to be taken?
PCI does require protection for card data at rest and in transit, so yes, this will require you to take steps to comply.
This is covered in great detail on Security Stack Exchange using the PCI-DSS tag.
Yes, if you transfer card data somewhere (no matter - between user browser and your server, between your scripts, between script, database and back, between your server and PayPal / Authorize.net / whatever) - you must make all this channels secure.
Say, with SSL layer. Do everything using HTTP*S*, not just simple HTTP and make sure your server's SSL certificate is correct, and up to date.
According to the following quote, SSL provides point-to-point security:
Transport security is used to provide
point-to-point security between the
two endpoints (service and client).
If there are intermediary systems
between the client and the server,
each intermediate point must forward
the message over a new SSL connection.
a) What is meant by SSL providing point-to-point security?
b) Is SSL communication still possible between client and server, if intermediary system ( located between the client and the server ) forwards the message over a non-SSL connection?
c) Assuming it is possible ... I don't see why intermediary system forwarding messages over a non-SSL connection would provide less security, since messages are already encypted by original sender ( which is either client or server ) and thus can't be decrypted by an intermediary systems?
thank you
EDIT:
One limitation of transport security
is that it relies on every “step” and
participant in the network path having
consistently configured security. In
other words, if a message must travel
through an intermediary before
reaching its destination, there is no
way to ensure that transport security
has been enabled for the step after
the intermediary (unless that interme-
diary is fully controlled by the
original service provider). If that
security is not faithfully reproduced,
the data may be compromised
downstream. In addition, the
intermediary itself must be trusted
not to alter the message before
continuing transfer. These
considerations are especially
important for services available via
Internet-based routes, and typically
less important for systems exposed and
consumed within a corporate intranet.
Message security focuses on ensuring
the integrity and privacy of individ-
ual messages, without regard for the
network. Through mechanisms such as
encryption and signing via public and
private keys, the message will be
protected even if sent over an
unprotected transport (such as plain
HTTP).
I think the context of that quote is different than you seem to be assuming; by 'intermediate system', I think that quote means a system that must access the message in the middle (intentionally or not)... not just a router, but something actually decrypting, viewing and/or modifying the message.
Therefore, because SSL is 'point to point', the above is actually not possible without another, separate connection being made.
The messages are encrypted at the endpoints. The only way to have a non-SSL connection in the middle would be to emulate both endpoints somewhere in the middle, which would be extraordinarily difficult barring flaws in the SSL implementations on either of the endpoints.