This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Now we are trying to connect to iOS with database that includes "Authentication permission needed characteristics".
We could code/register the database that includes Authentication permission, and iOS initiates Authentication process just after CC2540 responds "Insufficient Authentication". An authentication process passes correctly, when but iOS reads the same characteristic that requires authentication again, Ti stack responds "Insufficient Authentication" again even both devices have already been authenticated. Sequence seems to be as followings:
Condition: characteristic A requires authentication
iOS reads characteristic A >>
<< CC2540 responds as Error with "Insufficient Authentication"
iOS sends "Pairing Request" >>
<< CC2540 responds "Pairing Response"
iOS sends "Pairing Confirm" >>
<< CC2540 responds "Pairing Confirm"
iOS sends "Pairing Random" >>
<< CC2540 responds "Pairing Random"
<< CC2540 sends "Encryption Information"
<< CC2540 sends "Master Identification"
<< CC2540 sends "Identify Information"
<< CC2540 sends "Identify Address Information"
<< CC2540 sends "Signing Information"
iOS sends "Encryption Information" >>
iOS sends "Master Identification" >>
iOS sends "Identify Information" >>
iOS sends "Identify Address Information" >>
iOS sends "Signing Information" >>
<< CC2540 responds as Error with "Insufficient Authentication" AGAIN
What should we add to our code?? Are there any procedures that we should to do after authentication toward Ti stack???
If I could receive any comments, it would be great.
Thank you for your cooperation.
Hello. Are you using MITM? Authenticated pairing means that MITM must be used, either with a passkey or OOB. Since OOB is not supported, the peripheral must support passkey display.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Willis1:
Our device can't support MITM, because our device is categorized as NoInput/NoOutput, which means our device is a "Just Works" device. So, as you pointed out, responding "Insufficient Authentication" error seems completely wrong approach for our device... thank you very much.
We are struggling about how our device can start Pairing procedure with Apple products. Regarding the guideline from Apple, our peripheral should not send Pairing Request to iOS devices. And if peripheral devices need pairing, peripheral should respond "Insufficient Authorization" or "Insufficient Authentication" error code.
I think what we can do to start pairing with iOS is just responding "Insufficient Authorization" error to the iOS device, isn't it? Otherwise there are no triggers for peripherals to initiate the pairing with iOS. If this Authorization procedure is a good option, I have a another question:
I know how to add the attributes with Authorization permission to database, but I don't know how to tell the stack that Authorization procedure is completed. Are there any magic API on the stack to tell this? Or do we need to set if-branches to attribute access handler function?? In the sample codes, there is only example that returns authorization error to the peer. Could you provide any usage for authorization related APIs? If you could comment on this, we would much appreciate it fully.
Thank you very much for your supports.
In reply to Daisuke1:
I don't know for sure, but perhaps returning an "Insufficient Encryption" error response might get the iOS device to initiate pairing.
If you look in our "HidEmuKbd" project and look at the function HidDev_ReadAttrCB in the file hiddev.c, you will see an example of returning ATT_ERR_INSUFFICIENT_ENCRYPT. This return is on the ATT layer. The settings which you are talking about (e.g. GATT_PERMIT_READ, GATT_PERMIT_AUTHN_READ) apply to the GATT layer and are exposed in the GATT characteristic declaration. The return values such as ATT_ERR_INSUFFICIENT_ENCRYPT are ATT error responses. I have always considered this to be a somewhat confusing/contradicting part of the core spec, but profiles such as the HID-over-GATT profile make use of this.
Like the HidEmuKbd project, you can set the GATT characteristic declaration properties to GATT_PERMIT_READ, but then if the link is not encrypted return ATT_ERR_INSUFFICIENT_ENCRYPT in the response.
We can control to respond the "Insufficient Authorization" error referring function HidDev_ReadAttrCB as you mentioned. Now, we can follow the iOS implementation. Thank you very much again.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.