I'm reading "Guide to Bluetooth Security" by NIST (available here). At page 22 (page 33 of the PDF), they describe the Secure Authentication scheme. From what I can understand, both the devices compute the same value, then they send it to each other and each device checks that the value it has received is the same that it has sent.

If the value is really the same, what's stopping the device that receives the value first to just send that same value back? I feel like either I'm missing something, or there's some error in this document.

It could very well be the second option since, in this same section, in the image the master sends its value first, while the text says that it's always the slave that sends its value before the master.

I couldn't find another description of this scheme.

  • Welcome to the community. From a guess point, I'm guessing that it's either a challenge system or a handshake kind of protocol like it usually is Jan 25 at 17:11
  • Thank you. Yes, it's a challenge system. It's supposed to authenticate both devices, but by sending back and forth the same value, only one device can be authenticated.
    – StefanoTrv
    Jan 25 at 17:42

2 Answers 2


The information in this publication seems to be wrong. Specifically it states

  • Step 4. The slave returns the most significant 32 bits of the h5 output as the computed response, the Signed Response (SRESslave), to the master.
  • Step 5: The master returns the most significant 32 bits of the h5 output as the computed response, the Signed Response (SRESmaster), to the slave.

This says that SRESslave and SRESmaster are both the "most significant 32 bits of the h5 output", i.e. that they are the same. But the example from the Bluetooth core specification actually shows on page 916 the following example:

7.2.7 h5()
output: 746af87e1eeb1137c683b97d9d421f911f3ddf100403871b362958c458976d65
SRES_C: 746af87e
SRES_P:  1eeb1137

Here SRES_C (SRES master) are the first 32 bit of the h5 and SRES_P (SRES slave) the next 32 bit, i.e. they are not the same.

And in 7.7.8 it clearly states

The output of h5 is taken as the 128 most significant (leftmost) bits of the output of HMAC-SHA-256. The first 32 bits (leftmost) become the SRES_C. The next 32 bits become the SRES_P. The final 64 bits become the Authentication Ciphering Offset (ACO)

  • 1
    Thank you! The publication also says "the remaining 96 bits of the 128-bit output are known as the Authenticated Ciphering Offset (ACO) value, which will be used later as input to create the Bluetooth encryption key", so that's another error.
    – StefanoTrv
    Jan 25 at 18:32
  • You mention SRES_C twice (once for master, once for slave), typo?
    – Bob
    Jan 31 at 8:00
  • @Bob: Thanks for the notification. I've fixed the typo. Jan 31 at 14:09

Found the answer. Section of the Bluetooth Core Specification (Version 5.4): they are two different values that are computed independently by each device. In other words, the document explains poorly this particular scheme.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .