Understanding authentication with SE05X

[Riz]

Hi @Kan_Li and others,

I just wanted to understand couple of things.

1. In my setup, the accessManager is built with "-DPTMW_SMCOM=T1oI2C -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_SCP=SCP03_SSS" and the client application is built with "-DPTMW_SMCOM=JRCP_V1_AM -DPTMW_SE05X_Auth=UserID -DPTMW_SCP=None".

I have used the Delete and Provision example to provision the userID and other keys into the SE05X. When I run the client, I see below (log snippet below)

App   :INFO :Using default PlatfSCP03 keys. You can use keys from file using  ENV=EX_SSS_BOOT_SCP03_PATH

...

 :WARN :Communication channel is with UserID (But Plain).

sss   :WARN :!!!Not recommended for production use.!!!

...

I have passed the required authID from the client and the connection looks proper. What confuses me here is the warning which says "Communication channel is with UserID (but plain). Not recommended for production use".

Could you please let me know this warning is shown although the communication between the accessManager and SE05X is secured here with PlatfSCP03 keys.

2. Among the three different authentication mechanisms available, Could you please elaborate on what authentication mechanism would make sense in what scenario?

3. As per my understanding, the authentication based session here is only required in order to enforce that a client with a certain auth identifier should be able to open an authenticated session with the SE05X and do certain actions ( say create, delete etc. based on policy defined for respective auth Identifier) on the SE05X. Is the understanding correct?

4. The openssl_provisionRSA.py example (under sss/plugin/openssl/scripts) supports "--auth_type" parameter for provisioning the SE but the openssl_RSA.py which runs few sign/verify and encrypt/decrypt operations on SE is not accepting any auth_type parameter. Does this mean that the auth_type is not necessary while using openssl engine for crypto operations with SE ? and auth_type is only necessary during provisioning?
Could you clarify?

Hope the questions were clear. Looking forward to hear from you.

Regards,
Riz

[Kan_Li · Accepted solution]

Hi @Riz ,

Please kindly have my comments as below:

1. In my setup, the accessManager is built with "-DPTMW_SMCOM=T1oI2C -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_SCP=SCP03_SSS" and the client application is built with "-DPTMW_SMCOM=JRCP_V1_AM -DPTMW_SE05X_Auth=UserID -DPTMW_SCP=None".

I have used the Delete and Provision example to provision the userID and other keys into the SE05X. When I run the client, I see below (log snippet below)

App :INFO :Using default PlatfSCP03 keys. You can use keys from file using ENV=EX_SSS_BOOT_SCP03_PATH

...

:WARN :Communication channel is with UserID (But Plain).

sss :WARN :!!!Not recommended for production use.!!!

...

I have passed the required authID from the client and the connection looks proper. What confuses me here is the warning which says "Communication channel is with UserID (but plain). Not recommended for production use".

Could you please let me know this warning is shown although the communication between the accessManager and SE05X is secured here with PlatfSCP03 keys.
- No worry. This warning is just for the connection between the client and AccessManager, since the communication between the accessManager and SE05X is secured within PlatformSCP there should be no issue then.

2. Among the three different authentication mechanisms available, Could you please elaborate on what authentication mechanism would make sense in what scenario?
- Actually it depends your application, you know , there are 3 types of user sessions:
UserID Session (PIN-based authentication)
AESKey Session (AES-Key-based)
ECKey Session (opened by EC public key or ECKeypair)
Though the UserID can be used to set up a user session with SE050, but the communication is not secured, so you have to enable platformSCP for secure messaging purpose.
The other two sessions are both secure messaging channels, and they can also be encapsulated within the platform secure channel.
The difference between AESKey and ECKey sessions is AESKey is symmetric authentication type while ECKey is an asymmetric authentication type, and as far as I know AES authentication is faster than ECKey authentication.

3. As per my understanding, the authentication based session here is only required in order to enforce that a client with a certain auth identifier should be able to open an authenticated session with the SE05X and do certain actions ( say create, delete etc. based on policy defined for respective auth Identifier) on the SE05X. Is the understanding correct?
-Yes, you are right, and the authentication based session can also help to secure the communication between host and SE050 to provide end-to-end protection.

4. The openssl_provisionRSA.py example (under sss/plugin/openssl/scripts) supports "--auth_type" parameter for provisioning the SE but the openssl_RSA.py which runs few sign/verify and encrypt/decrypt operations on SE is not accepting any auth_type parameter. Does this mean that the auth_type is not necessary while using openssl engine for crypto operations with SE ? and auth_type is only necessary during provisioning?
Could you clarify?
- As I mentioned before, the authentication based sesson can also help to secure the communication between host and SE050 to provide end-to-end protection. So for test purpose, you may set auth_type = None, but for real application, you better use either of the above authentication type within the platform secure channel.

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

[Riz]

Hi @Kan_Li ,
Thank you for your response.

Please find my follow-up queries with "[Riz]" below:

1. In my setup, the accessManager is built with "-DPTMW_SMCOM=T1oI2C -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_SCP=SCP03_SSS" and the client application is built with "-DPTMW_SMCOM=JRCP_V1_AM -DPTMW_SE05X_Auth=UserID -DPTMW_SCP=None".

I have used the Delete and Provision example to provision the userID and other keys into the SE05X. When I run the client, I see below (log snippet below)

App :INFO :Using default PlatfSCP03 keys. You can use keys from file using ENV=EX_SSS_BOOT_SCP03_PATH

...

:WARN :Communication channel is with UserID (But Plain).

sss :WARN :!!!Not recommended for production use.!!!

...

I have passed the required authID from the client and the connection looks proper. What confuses me here is the warning which says "Communication channel is with UserID (but plain). Not recommended for production use".

Could you please let me know this warning is shown although the communication between the accessManager and SE05X is secured here with PlatfSCP03 keys.
- No worry. This warning is just for the connection between the client and AccessManager, since the communication between the accessManager and SE05X is secured within PlatformSCP there should be no issue then.

[Riz]:

Thanks. But isn't this warning misleading then?

"Not recommended for production use".

If Communication between the accessManager and SE are protected with PlatformSCP and client uses userID for authenticating the session, we still end up getting warnings in the logs.

Please clarify.

2. Among the three different authentication mechanisms available, Could you please elaborate on what authentication mechanism would make sense in what scenario?
- Actually it depends your application, you know , there are 3 types of user sessions:
UserID Session (PIN-based authentication)
AESKey Session (AES-Key-based)
ECKey Session (opened by EC public key or ECKeypair)
Though the UserID can be used to set up a user session with SE050, but the communication is not secured, so you have to enable platformSCP for secure messaging purpose.
The other two sessions are both secure messaging channels, and they can also be encapsulated within the platform secure channel.
The difference between AESKey and ECKey sessions is AESKey is symmetric authentication type while ECKey is an asymmetric authentication type, and as far as I know AES authentication is faster than ECKey authentication.

[Riz]

Your comment: "Though the UserID can be used to set up a user session with SE050, but the communication is not secured, so you have to enable platformSCP for secure messaging purpose."

With "enable PlatformSCP" here, if you meant connection between accessManager and SE05X? If yes, that is already done.

But with "enable PlatformSCP" here, if you meant connection between the client and AccessManager, then below reference from the manual (AccessManager section) says:

"The client processes that connect to the Access Manager must be built in a separate build environment. All session authentication mechanisms are supported, platform SCP03 must be off (platform SCP03 is handled by the Access Manager)."

Can you clarify?

3. As per my understanding, the authentication based session here is only required in order to enforce that a client with a certain auth identifier should be able to open an authenticated session with the SE05X and do certain actions ( say create, delete etc. based on policy defined for respective auth Identifier) on the SE05X. Is the understanding correct?
-Yes, you are right, and the authentication based session can also help to secure the communication between host and SE050 to provide end-to-end protection.

4. The openssl_provisionRSA.py example (under sss/plugin/openssl/scripts) supports "--auth_type" parameter for provisioning the SE but the openssl_RSA.py which runs few sign/verify and encrypt/decrypt operations on SE is not accepting any auth_type parameter. Does this mean that the auth_type is not necessary while using openssl engine for crypto operations with SE ? and auth_type is only necessary during provisioning?
Could you clarify?
- As I mentioned before, the authentication based sesson can also help to secure the communication between host and SE050 to provide end-to-end protection. So for test purpose, you may set auth_type = None, but for real application, you better use either of the above authentication type within the platform secure channel.

[Riz]:

As mentioned, the opensslRSA.py example, doesn't support --auth-type parameter at all, so if we want to make use of authentication based sessions with openssl for Secure operations, how can we do it?

Regards,
Riz

[Kan_Li]

Hello @Riz ,

Please kindly have my comments as below:

[Riz]:

Thanks. But isn't this warning misleading then?

"Not recommended for production use".

If Communication between the accessManager and SE are protected with PlatformSCP and client uses userID for authenticating the session, we still end up getting warnings in the logs.

Please clarify.

-Normally this message is triggered by the connection type between client and SE, in case the accessManager is in the middle of them, it is triggered anyway as the client side doesn't know the connection details between SE and accessManager, it works as if the accessManager is not there. so I don't think it would be misleading in that case, it just kindly remind you to check if the communication channel is really not secured. Alternatively you may comment out this warning in simw-top\sss\src\se05x\fsl_sss_se05x_apis.c to avoid this feeling.

[Riz]

Your comment: "Though the UserID can be used to set up a user session with SE050, but the communication is not secured, so you have to enable platformSCP for secure messaging purpose."

With "enable PlatformSCP" here, if you meant connection between accessManager and SE05X? If yes, that is already done.

But with "enable PlatformSCP" here, if you meant connection between the client and AccessManager, then below reference from the manual (AccessManager section) says:

"The client processes that connect to the Access Manager must be built in a separate build environment. All session authentication mechanisms are supported, platform SCP03 must be off (platform SCP03 is handled by the Access Manager)."

Can you clarify?

- I mean the connection between accessManager and SE05X, and yes , it is already done, so no warry here.

[Riz]:

As mentioned, the opensslRSA.py example, doesn't support --auth-type parameter at all, so if we want to make use of authentication based sessions with openssl for Secure operations, how can we do it?
-Actually the auth-type is determined during the openssl engine building within the MW, so the specified authentication would start automatically when you run any openssl command, in other words, you can not specify the auth type on the fly, it is defined before the MW building, in case you want to use another type, you have to rebuild the MW.

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

[Riz]

Thanks for your response. I have one query, see below.

"-Actually the auth-type is determined during the openssl engine building within the MW, so the specified authentication would start automatically when you run any openssl command, in other words, you can not specify the auth type on the fly, it is defined before the MW building, in case you want to use another type, you have to rebuild the MW."

Ok got it. The auth-type (Whether None, UserID, AES etc.) will be set during the openssl engine build within MW.

But how would the client using the openssl would authenticate itself? How would the client send authID in this case?

And say you have more than 1 client which have different policies set, how will each client authenticate themselves before actually talking to SE?

Could you please clarify. It would also help if you could share any example if available.

[Kan_Li]

Hi @Riz ,

Sorry, I might mislead you here, any Auth type defined except None for MW building would start the authentication process automatically when you run any ex_xxx examples such as ex_ecc out of the MW, but the example code itself doesn't contain the authentication part, neither for the openssl engine which provides an interface with external crypto devices for some cryptographic functionalities, of course you may implement your user application like this ,  but it is also free for user applications to set up an authenticated session in case Auth type defined as None for MW building, with the help of API such as ex_sss_boot_open_on_id(),   you may refer to the demo of se05x_ConcurrentEcc for details. alternatively you may refer to openssl_provisionRSA.py for more details.

Hope that helps,

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

[Riz]

Hi @Kan_Li ,

Thanks for your response.

I looked into openssl_provisionRSA.py code, I could see that internally in prepare_host_session.py (method prepare_host), they are setting the default authID

self.auth_id = authkey.SE050_AUTHID_USER_ID.

This is fine, we may need to adapt here if we want our client application to authenticate itself with a different authID apart from the default one.

This is internally making use of the SSS APIs.

My question is now related to opensslRSA.py example, if I see the example invocation, it expects the connection data, port number etc. from the user but doesn't take auth-type or auth-id as inputs.

And the sign/verify operations are done as below:

log.info("### PUBLIC ENCRYPT USING SSS - PKCSV1.5")
run("%s rsautl -engine %s -encrypt -inkey %s -out %s -in %s" %
(openssl, openssl_engine, rsa_ref_key_pair, encrypt_data, input_data))

Taking opensslRSA.py as an example, could you tell me how would I be able to pass "auth-id" for opening a session.

Thanks, 
Riz

[Kan_Li]

Hi @Riz ,

Actually the example binds the auth_type with auth_id together as defined in const.py, where you may find the definition of AUTH_TYPE_MAP. so you needn't pass the auth_id as well, auth_type is enough, and you may refer to openssl_provisionRSA.py for details regarding opening a session , and of course you may extend the definition of AUTH_TYPE_MAP according to your application.

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

[Riz]

Thanks @Kan_Li for your prompt responses.
So in a nutshell what I understand is, if I want to enable user authentication based sessions in my application using openssl, I would first use session_open(...) as given in openssl_provisionRSA.py (which internally uses SSS APIs) to open an authenticated user session and then perform any sign/verify operations with openssl once session is established.
Is my understanding correct?

I have couple of other questions too, please have a look below.
Hope to hear from you soon.

1. Here (Solved: How to prevent unauthorized object creation on SE0... - NXP Community) you have mentioned that the "Disable object creation" API would disable objection creation on the SE. But is there a way for a specific "authenticated" user to enable again and create new objects if required at later point in time?

2. Is there a way to set a policy at SE level and not at key/crypto object level?
I mean can I configure saying only this authID should be able to create or delete objects on the SE? Like a SuperUser authID? How?

For instance, we initially use auth=0 and write different AuthKeys (userID, AESKey or ECKey) and other crypto objects on SE. But later point in time we would only want authenticated users to perform create/update/delete operations.

Regards,
Riz

[Kan_Li]

Hi @Riz ,

Please kindly have my comments as below:

Is my understanding correct?

- Yes, your understanding is correct.

1. Here (Solved: How to prevent unauthorized object creation on SE0... - NXP Community) you have mentioned that the "Disable object creation" API would disable objection creation on the SE. But is there a way for a specific "authenticated" user to enable again and create new objects if required at later point in time?

-No. Actually the "Disable object creation" API has two options: Persistent or Transient . Persistent locks remain over the lifetime of the product, transient locks are unlocked when deselecting the applet.

2. Is there a way to set a policy at SE level and not at key/crypto object level?
I mean can I configure saying only this authID should be able to create or delete objects on the SE? Like a SuperUser authID? How?

- Yes, it is possible. Just as I mentioned in https://community.nxp.com/t5/Secure-Authentication/How-to-prevent-unauthorized-object-creation-on-SE... , you may fill the whole memory with dummy objects which contain a access policy for some authID like a SuperUser, These then would need to be deleted via this authID to make space for new objects. The dummy objects can be any type, so that you may just update them in some cases.

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

[Riz]

Thanks @Kan_Li .

In the authentication based sessions, I think the policies really make sense to have a better control on the secure objects on SE.

But the client application here would first need to authenticate itself with an authID.. and in that sense authID needs to be very secure since no malicious application gets hold of it.

Do you have a better recommendation on the authID management? Storing and accessing of authID?

Regards,
Riz

[Kan_Li]

Hi @Riz ,

Regarding the authID management, I would recommend using the secure host controllers which support secrets provision such as  LPC55S6x and LPC55S2x families, so you may provision the AESKey or ECCKey pair into such MCUs without hardcode them into your application code. Please kindly refer to the following links for more details.

Smart Card Trust Provisioning landing page:

https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/smart-card-t...

Java Card Trust Provisioning Sales Pack

https://www.nxp.com/webapp/secure/multiDownload.sp?colCode=SMART-CARD-TRUST-PROVISIONING-DISTY

MCUXpresso Secure Provisioning Tool (SEC) landing page:

https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-s...

MCUXpresso Secure Provisioning Tool (SEC) Fact Sheet:

MCUXpresso Secure Provisioning Tool – Fact Sheet

NXP Community: MCUXpresso Secure Provisioning Tool:

https://community.nxp.com/community/mcuxpresso/mcuxpresso-secure-provisioning-tool

Hope that helps,

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