Recovering from OP state

[mac-apt]

0xE0F0 has been put into OP state with trustm_metadata -w 0xE0F0 -O command. Current flags are: LcsO:0x07, C:LcsO<0x07, E:ALW, Algo:ECC256, Key:Auth, What`s the way to put it back to LcsO:0x01 or otherwise make it usable?

[ying-css]

Hi @mac-apt, No, it is impossible to put it back to LcsO:0x01 since the Lcs is implemented in a way that the four primary states only progress in one direction from a lower value to a higher value(e.g. initialization(in)=>operational(op) state), but even in operational state, the key still can be used. Thanks.

[mac-apt]

So, what you say is that in this CLI Infineon implemented easily accessible, harmless looking, warning-less, and non-reversible functionality, which essentially pushes register's self-destruct button (reading register is pointless, if you can't make any changes). What was the purpose for this, and is there any plan to correct this serious design flaw? Also, what`s the way to fix LcsO outside of CLI? Reflashing chip? Anything that can be done in home environment?

[ayushev]

Hello @mac-apt

I understand your concern, it is indeed very frustrating. Metadata handling is somehow complex, as there are many options. Under certain curcumstances the lifecycle state is a reversible action, a user should however prepare the corresponding access conditions accordingly. In the getting started guide there are many examples in regards to the protected data/metadata/keys update. Together with the corresponding tool you prepare any data to be updatable. If you have a specific use case in mind, please feel free to ask a question in the "Discussion"tab, or right here, after you become more familiar with it in Solution Reference Manual, pdf . We can support you in preparing the metadata expression.

To you point: Setting the Lifecycle state to the operational state doesn't kill the register, or the slot 0xe0f0, but make it operational, it means that you can do whatever you want with this, as previously, it is just that you can't change most of its properties and content, also a new keypair cannot be generated on this slot (but you can use other slots). There is a warning, in the readme itself, but as a similar issue happens already the second time, we should change the code to ask a user whether they want to continue the action. Thank you for this.

Also, it is important to denote, that you have changed the Lifecycle state (to Operational) only for one particular slot (0xe0f0)-  https://github.com/Infineon/optiga-trust-m/wiki/Data-and-Key-Store-Overview, you still can use it as previously; e.g. to sign data etc. What changed is that you can't generate a new keypair on this slot, and only on it. Please let me know if I missed something.

Usually this slot (0xe0f0) comes together with a certificate provisioned in the factory (slot 0xe0e0), unless you need to use this slot for your own needs to generate a new certificate and you can't use other slots we don't recommend to substitute it or change, only if putting the change access conditions to Operational.

[mac-apt]

Thank you @ayushev for your rich and roundabout input, but two of my questions still remain unanswered:

1. What's the way to fix LcsO's value outside of CLI?
2. Why setting LcsO to (non)operational feature was introduced to CLI in the first place?

Also, regarding special certificate imbued in 0xE0F0, I couldn't find any information regarding the special traits of that slot in Solution Reference Manual except for it having C:NEV set by default (which I managed to change to Lcs0<7, and generate new key for it, before further keygens became impossible for some reason - even before OP fiasco happened). Where could I find more details on that matter?

[ayushev]

@mac-apt thank you, you are right!

1. What's the way to fix LcsO's value outside of CLI?
2. From the PC side using Python (you need an Trust M EvalKit or an USB-I2C converter board for this):
   • http://python-optiga-trust.readthedocs.io/
   • https://github.com/Infineon/python-optiga-trust/
3. From the embedded software side (write_metadata and read_metadata)
   • Example: https://github.com/Infineon/optiga-trust-m/blob/trust_m1_m3/examples/optiga/example_optiga_util_write_data.c#L192
   • API: optiga_util_write_metadata optiga_util_read_metadata
4. There is another tool with GUI, similar to the python but more user friendly, but it is currently in unreleased state.

Why setting LcsO to (non)operational feature was introduced to CLI in the first place?

I'm not sure I understood your question, but CLI doesn't perform something if user doesn't request this action, it is just a tool to communicate with the device. If the question is about why the lifecycle state was not operation by default. Then the question is that the sample you have is for evaluation perposes, and if you would like to make it part of your product a user is expected to change the lifecycle of objects (or the complete chip) or any other settings based on the usecase. As developers might have different usecases, and if we make the chip operational the filed of changes will be narrowed down significantly.

Where could I find more details on that matter?

OPTIGA_Trust_M_Keys_And_Certificates_v3.10.pdf might help to understand what infrtustructure was used to populate the chip, including the format of the certificate and its content.

A bit more highlevel description can be found here

[mac-apt]

From the embedded software side (write_metadata and read_metadata)

Example: https://github.com/Infineon/optiga-trust-m/blob/trust_m1_m3/examples/optiga/example_optiga_util_write_data.c#L192
API: optiga_util_write_metadata optiga_util_read_metadata 

So, I tried this solution as I don't own any of the hardware pieces mentioned earlier, and didn't work. The metadata I'm using is:

static const uint8_t metadata [] = {
    //Metadata tag in the data object
    0x20, 0x03,
        //Lcs0 tag in the metadata
        0xC0, 0x01, 0x01
};

...and the result is:

pal_loger_write : [optiga example] : Failed with return value - 0x8005

Did I use wrong metadata or does your solution actually doesn't work?

I'm not sure I understood your question, but CLI doesn't perform something if user doesn't request this action, it is just a tool > to communicate with the device.

I see that "putting a small red button blowing up the room next to the light switch isn't the best design choice" metaphor won't get through here, so I'll try to rephrase my question a bit. As noticed earlier, you've already had two customers unhappy with the feature cripples a slot and the only potentially possible solution is for user to implement his own recovery tool (which is pretty much what was suggested to me earlier). Can you give me an example (maybe even hypothetical) of a customer that's happy with the current state of things? To put it even shorter: add an option of resetting Lcs0 value to your CLI, please and thank you.

[ayushev]

As I mentioened earlier, in you situation, the LcsO isn't recoverable, as this is a security countermeasure, imagine you would have a real product, and someone will try to reset this lifecycle from the outside. What I meant is following, it is possible to configure the "Change" Access Condition in the way, that allows you to update it even if LcsO is operational state, this procedure is know as "Protected Data/Key/metadata Update". We would like also to offer you a new, fresh Shield2Go, we already arranged it for you, please write to the CSSCustomerService@infineon.com

As noticed earlier, you've already had two customers unhappy with the feature cripples a slot and the only potentially possible solution is for user to implement his own recovery tool (which is pretty much what was suggested to me earlier).

it wasn't, what was suggested is a tool (besides existing CLI) on to update the metadata settings.

Can you give me an example (maybe even hypothetical) of a customer that's happy with the current state of things?

I'm sorry, but in my opinion this platform isn't the best place to discuss real or hypothetical customers.

To put it even shorter: add an option of resetting Lcs0 value to your CLI, please and thank you.

Resettin the LcsO is not possible by default as part of standard security coutnermeasure, otherwise anyone would be able to do so, but it it is possible to configure any chip, to update Access Conditions (Read, Change or Execute) in the way, that allows you to updathe the value of the slot.

For example, by default, noone can errase a private key, which is set to operational state, neither you, nor anyone else trying to break a product where your chip is mounted. But settings of that key (it's called metadata) can be configured in the way that a "Protected Data Update" is permitted, it means that in this case only you, as an owner of this product can update the content of the key, either invalidate it or update with a new value remotly.

[mac-apt]

@ayushev I sent a mail to CSSCustomerService@infineon.com a week ago as instructed, and have received no response until now. What gives?

[pwiegele]

@mac-apt Is you problem solved by now? Do you need any help?

[mac-apt]

@pwiegele The existence of critical software design flaw has been confirmed by Infineon employee by both being unable to show any counter-examples of customers satisfied with current design, and the same employee offering me a new Trust-M unit as the token of apology for damage done by the said flaw. Unfortunately, few weeks after the new unit supposedly being sent to my office, I still haven't received neither the product isellf, nor any detailed information regarding its whereabouts, so I can't really tell whether there was any actual incentive on Infineon's side to undo the damage, or was it just a part of time-buying scheme. Regardless of that, I still expect some work on this issue to be done on the software plane, as there's no reason for having the (easily accessible) means of partially crippling perfectly good hardware by means of software while not having any way of returning it to its default state. Reflashing would be good in such cases as the last resort, but I also don't see any reason, security-related or other, to not have the option of wiping the slot back to its pristine state without accessing the content; the option which should be as easily accessible, as the other one, that at this point does irreversible damage. I hope I can expect further support on this matter, please and thank you.