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.

bq34z100-G1: SHA-1/HMAC Authentication

Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQ26100, , BQ34Z100, BQSTUDIO

Hi

I've implemented the SHA-1/HMAC authentication scheme as described in SLUA389A (for the bq26100) , and my code produces the correct digest for the test key and message in that application report.

When I set the same key and send the same message however, I don't get the same digest back from the bq34z100-G1. I do get something that looks like a message digest, which changes if key or message are changed.

So, am I actually using the correct algorithm for this part?

And is the document incorrect (section 8.3.15.2) in saying the key should go in at 0x4C rather than 0x48? I have tried both.

I there something else I've missed?

Thanks for any pointers

Ian

  • The authentication engine should work the same for the bq34z100-G1. Could you provide a key, challenge and the Gauge Digest and I can check them to see whether I see the same?
  • Hi Thomas

    Below are some examples, the 'Local digest' is what I am generating, the 'bq34z100 digest' is what I am reading back from the gauge after sending the message.

    ------------------------------------------------------------------------------------------------------
    From the bq26100 datasheet example:
    Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Message: c8 2c a3 ca 10 de c7 26 8e 07 0a 7c f0 d1 fe 82 20 aa d3 b8

    Local digest: fb 8a 34 24 58 e0 b1 36 98 8c b5 20 3b b2 3f 94 df d4 44 0e
    bq34z100 digest: d9 d6 58 dd 3f 8c c0 92 ff f5 9b a4 f4 b6 e4 df 9f f8 a2 d0

    ------------------------------------------------------------------------------------------------------
    With the default key:
    Key: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
    Message: c8 2c a3 ca 10 de c7 26 8e 07 0a 7c f0 d1 fe 82 20 aa d3 b8

    Local digest: b4 6f 60 21 95 5e 20 3e e1 05 a2 23 5a e7 a0 ac c1 ff 0a ed
    bq34z100 digest: a8 9f 35 e7 16 3a 1f 0d 4f 8d ee fe 10 2d a4 91 5e a5 e4 c3

    ------------------------------------------------------------------------------------------------------
    With a zeroed message:
    Key: 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
    Message: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    Local digest: 2f a2 7c eb 5b 61 64 84 62 0f e3 22 17 c2 9b 0a 8e 3c f3 f0
    bq34z100 digest: f0 f3 3c 8e 0a 9b c2 17 22 e3 0f 62 84 64 61 5b eb 7c a2 2f

    ------------------------------------------------------------------------------------------------------
    And both zeroed:
    Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Message: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    Local digest: 86 8d 54 93 eb ad 51 f1 28 e3 14 aa 40 55 f5 ef 54 c6 26 69
    bq34z100 digest: 48 f7 c4 b3 5c 91 29 7a 95 92 ed 86 04 ed 45 6d ae 77 cf 86
    ------------------------------------------------------------------------------------------------------

    I have access via bqStudio if that can provide any further useful diagnostics for you.

    Many thanks for your time, regards
    Ian
  • Ian,

    The Message has to be written to the device in reverse byte order. e.g.

    for:

    c82ca3ca10dec7268e070a7cf0d1fe8220aad3b8

    enter:

    b8d3aa2082fed1f07c0a078e26c7de10caa32cc8

    The Digest will be returned in reverse byte order as well.

    I modified the bqz to add an Authentication tool to the bqStudio platform. This should help with the experiments.You can place it into this directory.

    C:\ti\BatteryManagementStudio\config

    Tom

    5873.0100_0_16-bq34z100G1.bqz

  • Hi Thomas

    Thanks for that, I had overlooked the byte order, and the symmetric default and example keys masked it.

    The authentication tool is very useful and has allowed me to try some more live data. I've found using an all-0 key does appear to elicit an incorrect gauge digest, while, say, 10000000000000000000000000000000 gets the correct response. I wonder if you can reproduce this?

    So, apart from this I'm good,  thanks again,

    Ian