• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 325 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ76942: Are there any restrictions on the allowed values for the BQ76942 security keys?

Steve
Intellectual 360 points
Part Number: BQ76942

Hello,

I am using a BQ7694201 device and need to select values to use for the security keys.

To transition between the security modes the keys must be written consecutively to the sub-command address (0x3E and 0x3F).  The process to execute a sub-command requires writing the appropriate command value to the sub-command address so I was wondering if this places a restriction on the values that can be used for the Unseal and Full Access keys?  Specifically, is it permitted to select a key value that has the same value as one of the commands that is listed in the 'Subcommands Table' of the device reference manual?

Thank you.

Steve

  • 0
    TI__Mastermind 42060 points

    Hello Steve,

    This is a really good question! There should be no restrictions to this as far as I am aware. Usually there are two steps to unseal the device, each must be done within a certain amount of time, so in my assumption, I believe that even if it shares some similarity to a known-subcommand, the combination of the two steps may let the part know that it was an unseal command.

    However, I can check this from my side as well, just to confirm that this is the case. If you do not mind I can provide you with an update on this by Monday EOD. Is that okay?

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Intellectual 360 points

    Hi

    Thanks for the reply.  I noticed that the minimum value that is allowed for any security key is 0x0100 (not 0x0000 as I first misread it).  For a while I thought that would prevent any conflicts but then I noticed in the table of Command-Only Subcommands that there are many commands with values higher than that.


    Yes please, if you could find out any other information from your side that would be good to know.

    Thanks again,

    Steve

  • 0 in reply to Steve
    TI__Mastermind 42060 points

    Hello Steve,

    Apologies, did not have much time to look into this today!

    I am hoping I can test things out tomorrow.

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Intellectual 360 points

    Hi

    No problem - I know how that works Slight smile

    It's not holding me up in any way so whenever you can look into it would be appreciated.

    Thanks,

    Steve

  • 0 in reply to Steve
    TI__Mastermind 42060 points

    Hello Steve,

    I actually had some time to test this today!

    I set the UNSEAL/FULLACCESS keys to the following values (All which are RAM register addresses):

    Then I sealed my device and tried using the these keys to UNSEAL it. There were no problems here. It was able to properly unseal! Slight smile. There were no conflicts.

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Intellectual 360 points

    Hi ,

    Thanks for trying that out.  Actually I was more concerned about conflicts with commands that could result in unintended actions.  For example, if you were to select the following key pair:

    0x2857, 0x29A3

    The writing the keys consecutively could force the command-based Permanent Fail because the first key is the command for PF_FORCE_A and the second key is the command for PF_FORCE_B (in the table of Command-only Subcommands).

    Similarly if one of the keys had a value 0x7C40 it could trigger a change in communications mode to HDQ.

    Does that make sense or am I missing something here?

    Steve

  • 0 in reply to Steve
    TI__Mastermind 42060 points

    Hello Steve,

    That is partly why I decided to choose the keys I showed in the image!

    0x9234 is the Power Config register and 0x9236 is REG12 Config.

    While 0x925b and 0x925d are actually the same address to the Full Access Keys.

    Now, when you unseal the device, you are not sending 0x2857 and 0x29A3 consecutively, you are writing to 0x3E/3F separately for both steps. So you are not writing anything to the registers, just to 0x3E/3F.

    The sequence to UNSEAL and go to FULLACCESS mode is the following (Assuming the keys in my example)

    • Write 0x3E/0x3F with 0x34 0x92
    • Write 0x3E/0x3F with 0x36 0x92  (These first 2 steps need to be written within 4 seconds of each other and will put the device in UNSEALED mode).
      • This UNSEALs the device
    • Write 0x3E/0x3F with 0x5b 0x92
    • Write 0x3E/0x3F with 0x5d 0x92 (These last 2 steps need to be written within 4 seconds of each other and will put the device into FULLACCESS mode).
      • This gives you FULLACCESS of the device.

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Intellectual 360 points

    Hi

    I think I understand your test case.  For Data Memory addresses I can see that there should not be a conflict with key values because, as you say, we are only writing the key to 0x3E/0x3F.  The worst possible side effect is the BQ76942 device will start to load its transfer buffer with data corresponding to the Data Memory address.

    However, that is not the case with Command-only Subcommands.  If we revisit my example:

    0x2857 is the command for PF_FORCE_A and 0x29A3 is the command for PF_FORCE_B

    To force a command-based Permanent Fail I would need to send the command PF_FORCE_A followed by the command PF_FORCE_B within 4s with no writes in between.

    Therefore:

    • Write 0x3E/0x3F with 0x57 0x28
    • Write 0x3E/0x3F with 0xA3 0x29 (within 4s of previous command, no writes in between)

    If I happened to pick 0x2857 as the value for ‘Security:Unseal Key Step 1’ and 0x29A3 as the value for ‘Security:Unseal Key Step 2’ then the procedure to UNSEAL the device would be:

    • Write 0x3E/0x3F with 0x57 0x28
    • Write 0x3E/0x3F with 0xA3 0x29 (within 4s of previous key, no writes in between)

    Writing the keys to transition to UNSEALED mode is then identical to writing the sequence of commands to force a command-based Permanent Fail.  Note that both these key values are in the valid range (0x0100:0xFFFF) as specified in the reference manual.

    Sorry to keep dragging this question out Slight smile but I still can’t see how this is not a conflict.

    Thanks for your patience,

    Steve

  • +1 in reply to Steve
    TI__Mastermind 42060 points

    Hello Steve,

    Don't be sorry! That is actually a very good question and I did not consider that case. Yes, you are correct, the Security Keys should not be any of those Direct Command values! That could be problematic.

    I brought up internally to the engineer who wrote the documentation for this device and he confirmed this as well. He was not aware that this was not written in the documentation, so he will likely update this in the next update of the Technical Reference Manual!

    Thank you for catching this up and bring it up to our attention! Apologies for the confusion haha. Do let me know if you have any other doubts/concerns!

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Intellectual 360 points

    Hi ,

    Thanks for passing that information on.  I looked again and I definitely don't see anything in the TRM that would warn about that, although it might be in some other documentation.  The chances of picking an unsuitable key value are pretty low, but still good to know ahead of time.

    Take care,

    Steve