Implementing PIN protection and PIN change with the SE050.

[S_GUED]

Hi,

Using the SE050, I am able to create keys that are protected using a PIN.
For that, I first create a UserID with the PIN value as the data.
Then I create the keys and other objects with a policy restricting the use to a session authenticated with the UserID.

This works and I am able to control access to the keys.

However I also want to be able to update the PIN, with knowledge of its previous value.
For that purpose I can add a policy to the UserID when I create it, adding the ALLOW_WRITE and ALLOW_DELETE value.

However I am not able to update it. The ALLOW_WRITE policy does not appear to be of any use since the WriteUserID apdu can only be used to create UserIds, not update them, as confirmed Here and here by NXP support.
Deleting the UserID and recreating it with the new PIN value is also not working. After being deleted then recreated, a session opened with the UserID is fails to use the keys.

How can I implement PIN update functionality?

[S_GUED]

Hi,

Looking back at the commands I ran, it turns out I made a mistake with the ObjectIds which I used, and the use case works. I apologize for the mistake.

However this raises two new questions for me:

We want to allow deletion of PINs without authentication. However, this means that an unauthenticated attacker having access to the SE050 could delete the PIN and then recreate it to unlock access to the keys it protects. Is it possible to prevent unauthenticated deletion of a UserID if any other object references it in its policy?

Since the PIN change takes place in two steps, it is not atomic. This could lead to security issues if power is lost after the UserID is deleted, but before it is re-created. This topic also mentions this issue but is not resolved. How can we best prevent this from happening. We do not control the power source of our device, and a user could very well disconnect it while the operation is happening by mistake.

Thank you,
Sosthène

[Kan_Li]

Hi @S_GUED ,

Is it possible to prevent unauthenticated deletion of a UserID if any other object references it in its policy?

- Yes, you may attach the policy to the UserID and specify the Auth ID in the policy, for example, an ECC key pair , so that deletion is only possible in the session authenticated by this Auth ID.

Since the PIN change takes place in two steps, it is not atomic. This could lead to security issues if power is lost after the UserID is deleted, but before it is re-created. This topic also mentions this issue but is not resolved. How can we best prevent this from happening. We do not control the power source of our device, and a user could very well disconnect it while the operation is happening by mistake.

- I think you may use the edgelock2go secure cloud service to manage the secure objects such as UserID in the field.  Please kindly refer to https://www.nxp.com/products/security-and-authentication/secure-service-2go-platform/edgelock-2go:ED... for more details.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[S_GUED]

Hi, thank you for your response.

Yes, you may attach the policy to the UserID and specify the Auth ID in the policy, for example, an ECC key pair , so that deletion is only possible in the session authenticated by this Auth ID

I am aware of this. Let me reformulate my question so that I can be more clear:

We want to enable our users to protect themselves in case someone gets access to their device. For that they can protect their device through a PIN, which in turn is used as a UserID on the SE050 and protects access to secret keys.

In case the user forgets their PIN, we want to be able to factory-reset part of functionality of our product.
For that we need to enable them to delete specific PINs and user IDs.
However by allowing deletion of UserIds, we allow an attacker to delete and recreate the UserIds, and get access to the keys. We can't use an ECC or AES key to protect deletion of the UserID, because we do not have a way to protect them. We could store them with limited protection but then that voids most of the interests of using a Secure Element in the first place.

The only solution I see would be to use the factory reset functionality of the SE050 but there doesn't appear to be a way to limit the scope of the reset. We have multiple apps and PINs and would like to be  able to  reset  them independently.

[Kan_Li · Accepted solution]

Hi @S_GUED ,

With these requirements I would propose something like following:

The userID delete policy reference the actually to be protected key – which is not an authentication object:

Object ID	File Size	Object Class	Curve/Length	AuthObject	Policy (Authentication Object + applied Access Rules)	Auth attempts cntr	Auth attempts limit	TagLen for AEAD	min Output Length	Owner	Origin
0x00000001	16	UserID	N/A	Yes	0x00000002 DELETE	N/A	N/A	N/A	N/A	0x00000000	EXTERNAL
0x00000002		EC key pair	NIST P256	No	0x00000001 SIGN VERIFY 0x00000000 DELETE	0x00	0x00	N/A	N/A	0x00000000	EXTERNAL

The UserID has a policy to be deleted with the objectID of the actual key being protected (0x00000002). the actual key cannot be used to create a session as it is not an authentication key. So first the keypair needs to be deleted to make place for an authentication objecto to delete the UserID. In this way it can be ensured that the key needs to be deleted before the userID.

Process to partially factory reset the credentials (only delete 0x00000001+0x00000002):

• Delete EC Key Pair 0x00000002
• Create temporary auth object on 0x00000002 (with policy 0x00000000 DELETE)
• Authenticate with this object 0x00000002
• Delete UserID 0x00000001 – the ID part of the user’s credential is removed
• Delete temporary auth object 0x00000002

This needs one UserID per file, but it does not involve DeleteAll.

Further point:
UserIDs are not changeable - in case users should have the possibility to change PINs maybe AESKey should be used instead. The needed AES key could be hashed out of the user supplied PIN using e.g. HKDF or PBKDF2. When this is being done with an credentials only available to the SE this also slows down brute forcing the calculation of the key needed to try to authenticate so that due to this slow down no authentication try limit needs to be set to prevent excessive brute forcing.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Kan_Li]

Hi @S_GUED ,

How did you delete then create the new UserID? Was it the same as the old one except the PIN value?

Please kindly clarify.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------