2133148_en-US

[#1]

[enersys][Nextracker]Regarding the AES key provisioned via EL2Go

Hello Experts,

There are some follow ups from Enersys and Nextracker, Please kindly refer to the following for details.

Enersys:

Well, that’s good news that this is a bug that can be fixed.

However… it may be too late for us to use this key, as we already have devices provisioned and out in the field.

Is there any way to apply this read policy after the fact? I did see some policy-related commands in the ssscli documentation, but I’m not sure how to use them.

Nextracker: 

Reading the response, I am a bit confused on current status –

We already flashed close to 1000 elements, are these recoverable? Or do we need to scrap them all?

Also, am I understanding correctly that there is nothing we can do on our side to fix this (i.e. we are blocked until El2go it fixed by NXP)?

Last but not least, this response worries me of El2g0 maturity – using AES and secure provisioning seems to me  pretty basic SE functionality, if I understand correctly the response, it seems this was never used by any customer?? As I would expect this bug to arise for anyone trying to use it.

I have told them the policy can not be updated unless they delete the AES key and re-provision them manually or via EL2Go, but wondering if there is any better solution for this case, would you please advise? 

Best Regards,

Kan

Re: [enersys][Nextracker]Regarding the AES key provisioned via EL2Go

Hi Kan, 

like discussed earlier one option is provisioning new aes key with correct policies to new object id.

For other option(more details), where, if we want to use already provisioned aes key (which cannot be read), this example code can be used. 

Please find below two files: one is AES_key_without_read.cpp (changed to .c format as .cpp is not allowed to upload here) and other is aes_key_without_readtype_logs.txt.

If you use the code as mentioned in AES_key_without_read.cpp, it will just use checkobjectexist APDU and cipheroneshot apdu and will not use the readtype apdu as shown in aes_key_without_readtype_logs.txt.

So, using this you can use the already provisioned key without reading it.

One of the two options can be used.

Kind regards,

Parth

Re: [enersys][Nextracker]Regarding the AES key provisioned via EL2Go

Hi @nxg11900 ,

Thanks for the info! I will share with the customer. 

Best Regards,

Kan

Re: [enersys][Nextracker]Regarding the AES key provisioned via EL2Go

Hello Kan,

At Elgo portal now Read policy can be selected, this issue is fixed. It was small error, where for this one particular product type(se050) and for this one particular secure object, read policy was not not selectable and which is fixed now. 

It is not possible to change policy of secure object once it's already created in El2go or provisioned in device, with certain policies. And this ssscli policy related commands (for Enersys) are to create policy file which can be used/assigned  to an object when we create an object or display policy(referred by dump in MW doc: AN13030). 

These two options can be suggested for now, for the devices which are already in field:

1. Creating new AES key with right policies and provisioning it to a different object id.

2. for the already provisioned key instead of using "sss api" use "se05x api"( which is one layer below sss) and not read the AES secure object.

Kan, i will also see if we can work with sss api also for the already provisioned AES key.

Kind regards,

Parth