Is there more information about SE050-MW policy functionality?

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there more information about SE050-MW policy functionality?

287 Views
Contributor I

I have a question to policies and how these are handled when using the NXP plug&trust MW.

Is there a more comprehensive description available to the following aspects:

  - Authentication Object ID: its relation to sessions and how/whether a secure object can be (differently)

     accessed when a different authentication object ID is applied. A few examples would be highly appreciated.

  - How can I enforce that a particular key can be used for signing, but NOT for any other purpose?

  - Can you allow a security object for reading/re-write a particular User ID while when SCP03 is applied,

   only encryption/decryption allowed with same security object, e.g.

           UserID #1: reading/re-write

           SCP03: encrypt, decrypt

 -  Does SCP03 apply in parallel to a User ID session? What Authentication Object ID does apply?

 Thank you very much, Markus

se050‌

#Policy

Tags (2)
0 Kudos
6 Replies

97 Views
NXP TechSupport
NXP TechSupport

Hi Markus,

- Authentication Object ID: its relation to sessions and how/whether a secure object can be (differently)

accessed when a different authentication object ID is applied. A few examples would be highly appreciated.
-- An authentication object is a Secure Object that can be used to open a session. It has no relation with access for a secure object.

- How can I enforce that a particular key can be used for signing, but NOT for any other purpose?
-- You may enable the policy of "POLICY_OBJ_ALLOW_SIGN" for this key.

- Can you allow a security object for reading/re-write a particular User ID while when SCP03 is applied,

only encryption/decryption allowed with same security object, e.g.

UserID #1: reading/re-write

SCP03: encrypt, decrypt

-- When the USER ID has policy of "POLICY_OBJ_ALLOW_WRITE", it allows the write operation, but read operation is not allowed for USER ID object.

- Does SCP03 apply in parallel to a User ID session? What Authentication Object ID does apply?
-- No, it doesn't support. User sessions can only be set up from the default session, so users cannot open a new user session from within an existing user session.

Please kindly refer to https://www.nxp.com/docs/en/application-note/AN12413-SE050_APDU_specification.pdf  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.
-------------------------------------------------------------------------------

0 Kudos

97 Views
Contributor I

Hi Kan Li,

thank you for your prompt help! I think I am a step further. Let me post my comments and additional questions to get the point how the functional SE050 security works.

- Authentication Object ID: its relation to sessions and how/whether a secure object can be (differently)
accessed when a different authentication object ID is applied. A few examples would be highly appreciated.

-- [Kan_Li] An authentication object is a Secure Object that can be used to open a session. It has no
relation with access for a secure object.
-- [Markus] If I read page 23 section 3.7.1.2 table 8 within AN12413 as referred to below, I got the impression
that each policy is linked to the Authentication Object ID. If SCP03 is implemented using "Authentication Objects"
then I was assuming a relation between authenticated session and access rights.
As each policy contains a related Authentication Object ID, I was assuming policy compliant
access rule applies only when a particular authentication is achieved.

Asked in different way: if I code Authentication Object ID with 0x00000000 ("all other users"), does this assure
the policy and related access rules apply with all ways of Authentication (any combination of User ID, SCP03 on/off, etc.)?
I guess it is the case.

If correct, the recommendation in policy setting is probably to set the most strict access rules with
the "all other users" option and leave additional access to other policies.

My overall question is simply how do (multiple) policies work. When exactly are which policies enforced?
If an authentication object is NOT related to access, when do any particular policies and access rules apply
with given non-trivial Authentication Object IDs (not 0x00000000)?

E.g. I want to protect a secret ECC key against regeneration+overwrite, against reading (import/export),
against overwrites from external.

Related to that, I guess the origin (refer to table 2 section 3.2.4, table 4 section 3.2.7) is updatable, but not randomly,
in this sense: i.e. when security object was imported, origin can not be "ORIGIN_INTERNAL", it would change to
"ORIGIN_EXTERNAL" and this can not be manipulated, correct?


- How can I enforce that a particular key can be used for signing, but NOT for any other purpose?
-- [Kan_Li] You may enable the policy of "POLICY_OBJ_ALLOW_SIGN" for this key.
-- [Markus] understood


- Can you allow a security object for reading/re-write a particular User ID while when SCP03 is applied,
only encryption/decryption allowed with same security object, e.g.
UserID #1: reading/re-write
SCP03: encrypt, decrypt

-- [Kan_Li] When the USER ID has policy of "POLICY_OBJ_ALLOW_WRITE", it allows the write operation, but read
operation is not allowed for USER ID object.
-- [Markus] I start to understand how this works, however, as mentioned above, I probably shall NOT create
an (additional) policy that holds to "all other users" with "POLICY_OBJ_ALLOW_WRITE" included. Right?


- Does SCP03 apply in parallel to a User ID session? What Authentication Object ID does apply?
-- [Kan_Li] No, it doesn't support. User sessions can only be set up from the default session, so users cannot
open a new user session from within an existing user session.
-- [Markus] Aaah, that means UserID session, AESkey session (=SCP03), ECKey session (=FastSCP or SCP03),
Session-less access are all mutually exclusive, right? However, there is some relation as the sessions seem
to change in time according to a given sequence. I mean Figure 10, page 20, seciotn 3.6.3.3.
The figure tells me that
- SCP03 is an "authentication object" (title of the figure)
- After User authentication, SCP03 is applied (automatically?)
Same with ECKey session, figure 11. Is my impression wrong?


[Kan_Li] Please kindly refer to https://www.nxp.com/docs/en/application-note/AN12413-SE050_APDU_specification.pdf for more details.
[Markus] Thank you, I use version 2.8 December 2019.

I hope you understand my comments/questions. Many thanks and I wish you a nice day,

Markus Feuser 

0 Kudos

97 Views
NXP TechSupport
NXP TechSupport

Hi Markus,

Please kindly refer to the following for details.

if I code Authentication Object ID with 0x00000000 ("all other users"), does this assure
the policy and related access rules apply with all ways of Authentication (any combination of User ID, SCP03 on/off, etc.)?
--A Secure Object identifier is in the range of [0x00000001-0xFFFFFFFF]. The identifier 0x00000000 is invalid and shall not be used.

My overall question is simply how do (multiple) policies work. When exactly are which policies enforced?
If an authentication object is NOT related to access, when do any particular policies and access rules apply
with given non-trivial Authentication Object IDs (not 0x00000000)?E.g. I want to protect a secret ECC key against regeneration+overwrite, against reading (import/export),
against overwrites from external.
-- For this case, just specify the policy for this object during creation, excluding the policies that you need not.

I probably shall NOT create an (additional) policy that holds to "all other users" with "POLICY_OBJ_ALLOW_WRITE" included. Right?
--Yes, but as the identifier 0x00000000 is invalid and shall not be used, so you need not worry about this.

that means UserID session, AESkey session (=SCP03), ECKey session (=FastSCP or SCP03),
Session-less access are all mutually exclusive, right? However, there is some relation as the sessions seem
to change in time according to a given sequence. I mean Figure 10, page 20, seciotn 3.6.3.3.
The figure tells me that
- SCP03 is an "authentication object" (title of the figure)
- After User authentication, SCP03 is applied (automatically?)
Same with ECKey session, figure 11. Is my impression wrong?
--Actually SCP03 key is the "authentication object", and yes , After User authentication, the session is SCP03 protected automatically.

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.
-------------------------------------------------------------------------------

0 Kudos

97 Views
Contributor I

Hi Kan Li,

I did some homework and will post a zip file. I extended the python pycli to support policies. New are:

1. generate key with policy, e.g. prohitibiting redefine/readout or allow key for attestation:

  - python3 pySSSCLI.py own gen ecc <keyid> <curvetype> <policy>

2. read key with attestation:

  - python3 pySSSCLI.py own get attst <keyid> <pem file> <keyid_attst> <algorithm_attst>

3. get information on memory size in byte (persistent and/or transient):

  - python3 pySSSCLI.py own get freemem

The extensions do work as far as I have tested them - policies do have an effect! I would be great to get some feedback from you and/or the community here. Anybody else out there who added functionality?

Let me come back to the last open point we discussed in April:

"I probably shall NOT create an (additional) policy that holds to "all other users" with "POLICY_OBJ_ALLOW_WRITE" included. Right?
--Yes, but as the identifier 0x00000000 is invalid and shall not be used, so you need not worry about this."

Have a look to the SE050 MW simw-top/sss/ex/ex_sss_auth.h (lines 25-35), where 0x00000000 codes for "...NONE_AUTH...". This implies the 0x00000000 is in this context not invalid. I hope you get the point and what information I was looking for.

Many thanks again!

Markus

0 Kudos

97 Views
NXP TechSupport
NXP TechSupport

Hi Markus,

Some additional notes regarding this topic:

The object ID 0x00000000 cannot be used to create a secure object, but the usage in policies is valid and normal. E.g. to set a object to read-only, apply a policy of ALLOW_READ with specified auth object 0x00000000. 0x00000000 means in this context all users/no specific authenticated user.

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.
-------------------------------------------------------------------------------

0 Kudos

97 Views
NXP TechSupport
NXP TechSupport

Hi Markus,

This define is recommended to be used for readability.but functionally it serves no further purpose. The spec is right, you can not use the id "0x000000" for auth. Please kindly refer to the following for more details.

pastedImage_1.png

pastedImage_2.png

Hope that makes sense,

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.
-------------------------------------------------------------------------------

0 Kudos