Hi,
Our device is a source of information that we want to share with the user in our mobile application, however we would like to own the information and not let 3rd party write another mobile app and get the device information. For this purpose Bluetooth define a "Secure" challenge-response authentication: Both sides need to know some secret string and only if both are satisfied that the other side "know" the secret a connection will be permitted.
We use SPS profile to transmit the information to our mobile app.
1. Is this feature supported by SDK?
2. If yes, how to enable it?
Kind regards,
Raz
Keywords:
Device:
Hi razp,
1) If you mean that you would like to implement BLE security as defined by the BLE specification on the 580, then yes, it is supported by the SDK.
2) Be aware that there are quite a few options in BLE security with a number of pairing methods and security properties, please check the BLE specification for more info about this, additionally please have a look at the ble_app_security example in order to implement this kind of feature in your project.
谢谢mt_dialog.
Hi MT
如你提到，有quite a fewoptions.
I fail to find any reference to challenge-response authentication scheme. Perhaps it is referred by different name, can you be more specific?
Kind regards,
Raz
P.S.
我假设此功能是在SDK代码中实现的，它是一个设置正确配置来激活它的问题。
Hi razp,
您必须更具体地满足您的要求，BLE规范提供的安全性是标准的，并且SDK支持BLE优惠的所有方案，我无法判断挑战 - 响应身份验证方案的完全相同你的要求是什么。
对安全概览的一些事情进行了总结，以便为您提供一些指导。如果激活BLE安全性，这意味着您的设备以交换数据，它们必须通过配对过程。因此，这意味着为了启动您的外围设备将在连接或设备将连接到中央的安全请求以及连接器的主站尝试以安全特性进行读取或写入时，访问将被拒绝拒绝访问或写入。必须通过配对方法（交换后续连接所需的键），或者他必须通过加密（如果设备先前配对，检查设备上存在的键是否匹配）。
The BLE specification defines 3 security levels, no security, security level 1 and 2. In security level 1 (which i assume fits most to what you would like to do) you have two options, unathenticated pairing with encryption and authenticated pairing with encryption, the security 1 authenticated pairing with encryption for the BLE specification means that you will have to set a PIN or OOB data code for your device in order to access it and go through the pairing procedure therefore the authentication for the BLE spec is to know who is the device on the other side during the pairing procedure. In general even if you use the Just works method (without the Passkey entry) and you just pair with a random device you will be able to implement a challenge-response authentication scheme, since on each subsequent connection you will be able to drop each device that doens't present the ediv and rand keys that you have stored in your peripheral device in an encryption request attempt in order to retrive the bonding data that you have stored.
The scheme that you describe isn't fully implemented on the SDK and the examples, in some of the examples when you define the CFG_APP_SECURITY the security handlers are included (the functions in the user_callback_config.h file .app_pairing_request, .app_on_tk_exch_nomitm etc) and by setting the .security_request_scenario member in the user_default_hnd_conf struct in the user_config.h file a security request is send to the central and the device goes through the pairing procedure, but you will need extra implementation to deny access to additional centrals that will request connection and also you will have to set your security settings. A full security example is the one indicated above.
谢谢mt_dialog.
Hi MT,
Thank you for your comprehensive response.
The authentication scheme we would like to employ is defined in Bluetooth Core Specification Vol.2 - 5 AUTHENTICATION. This section refer to two schemes: "Legacy authentication" and "Secure Authentication".
My understanding from looking at the SDK code and your writing is that these authentication schemes are not implemented.
1) Is that correct?
2) Do you know of any implementation of this schemes external to SDK? Maybe one of your clients?
3) Do you know if these schemes implemented in Android and IOS?
你的反应是感激。
Kind regards,
Raz
Hi razp,
1) Regarding the Secure Authentication, this is something that is not supported from the 580, since the BLE stack that the SoC family uses implements only the mandatory features of the 4.2 specifications (it is 4.2 Qualified), that means that secure connections aren't supported. Regarding the Legacy authentication this is the standard authentication since the 4.0 spec that is supported from the SDK as it is mentioned in my previous post.
2）关于在SDK上实施安全性和身份验证，我相信您已经通过教程5配对，绑定和安全性了解。
3) As far as i know most of the android devices support this kind of scheme (legacy security).
谢谢mt_dialog.