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
