ImportExternalObject and POLICY_OBJ_ALLOW_IMPORT_EXPORT

[psvz]

Could you please confirm that if a secure object was created with default policy (no explicit setting for POLICY_OBJ_ALLOW_IMPORT_EXPORT), such object cannot be updated through ImportExternalObject channel?

Thank you.

[Kan_Li]

Hi @psvz ,

This policy has nothing to do with the ImportExternalObject command, it is related with ImportObject/ExportObject commands that are only against transient secure objects of type AESKey, DESKey, RSAKey or ECCKey.

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

[psvz]

Hi @Kan_Li ,

Can we go through ImportExternalObject together, please?

First of all, APDU guide states:

4.7.2 ImportExternalObject
Note: The APDU “ImportExternalObject” must not be used without first contacting NXP to avoid potential problems. If you have used or plan to use the APDU “ImportExternalObject,” please make sure you contact your NXP representative.

What are the problems? and Who at NXP can help me with this?

I am working with simw-top/demos/se05x/se05x_ImportExternalObjectPrepare/se05x_ImportExternalObjectPrepare.c

I fixed some obvious mistakes and get it to the final API Se05x_API_ImportExternalObject() which fails:

# ./xin -file skey.der -keyid 0x7FFF0202
smCom :INFO :Found Reader: Identiv uTrust 3700 F CL Reader [uTrust 3700 F CL Reader] (55022428201805) 00 00
smCom :INFO :Connecting to reader: Identiv uTrust 3700 F CL Reader [uTrust 3700 F CL Reader] (55022428201805) 00 00
sss   :INFO :Newer version of Applet Found
sss   :INFO :Compiled for 0x70200. Got newer 0x7022E
sss   :WARN :Communication channel is Plain.
sss   :WARN :!!!Not recommended for production use.!!!
App   :INFO :master shared Secret !!!!
App   :INFO :masterSk (Len=16)
      24 90 AD 4B    A8 A5 3B 45    EC 4B FE E3    FC C2 0D 39
App   :INFO :sessionEncKey (Len=16)
      B2 EC 1A 38    AE 8D B7 06    7F F8 D5 DA    A9 C6 3C 0F
App   :INFO :sessionMacKey (Len=16)
      6C 7C 0A 91    EA 71 EB 8A    FC 34 39 9F    C9 C2 8F 6A
App   :INFO :sessionRmacKey (Len=16)
      CB A5 74 1A    EE 56 93 77    F6 2A AB E4    A5 91 EA BB
App   :INFO :Initial MCV (Len=16)
      93 50 68 FA    15 6E 28 E6    C2 72 50 9C    31 35 8F 95
App   :INFO :gTxBuffer (Len=29)
      80 01 03 00    18 41 04 00    00 00 ED 43    10 48 45 4C
      4C 4F 48 45    4C 4C 4F 48    45 4C 4C 4F    31
sss   :WARN :nxEnsure:'ret == SM_OK' failed. At Line:7837 Function:sss_se05x_TXn
App   :ERROR:se05x_ImportExternalObjectPrepare Example Failed !!!...

I am happy to share the code if you would help.

[psvz]

Hi @Kan_Li ,

Does it mean anyone with physical access to SE can always update objects I created via external import route (I can't delete NXP-provisioned keypair 0X7fff0202)?

Which leaves us with only possibility to avoid such updates by  Se05x_API_DisableObjCreation( kSE05x_RestrictMode_RESTRICT_ALL ) ?

Unless I am missing anything?

Thank you 

[Kan_Li]

Hi @psvz ,

Unauthenticated user can not issue this command successfully, so you need not concern about this. Please kindly refer to the section for "Secure Object external import" 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.
-------------------------------------------------------------------------------

[psvz]

Hi @Kan_Li 

I am asking with reference to section 3.2.9 Secure Object external import in NXP APDU manual.

Anyone with physical access to the SE can get its public key with required ID (it is NXP-provisioned and cannot be removed).

According to the workflow documented, anyone with arbitrary host-side key-pair can, using that SE public key, perform WriteSecureObject command. Hence, rewriting anything they want.

What do I miss?

[Kan_Li]

Hi @psvz ,

The existing secure objects have their own policies which would protect them from overwriting by unauthenticated WriteSecureObject command. For more info regarding ImportExternalObject command, please contact your local NXP sales representatives, as some info is under NDA , we are not allowed to discuss it here.

Thanks for your patience and understanding!

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

[psvz]

Hi @Kan_Li ,

Need for NDA is a bit baffling.

NXP openly markets SE05X family and Se05x_API_ImportExternalObject() is part of associated middleware anyone can download. The API is publicly documented. 

This middleware further contains a usage example. It doesn't work for me because: 1/ lack of my experience, for which I ask for your kind assistance; 2/ inadequate documentation on NXP end, for which I am eager to help in return.

If you request an NDA, you imply that SE05X is vulnerable, contingent on knowledge of a secret you wish to protect with the NDA. Cryptographic primitives SE05X implements are all well-established in public domain. Public verifiability is paramount in matters of security.

Unless you admit that SE05X API is subject to intended vulnerabilities by NXP, could you please explain why you ask for NDA and what you aim to safeguard with it?

I would appreciate if you could please escalate this thread.

[Kan_Li]

Hi @psvz ,

We welcome technical discussion here, but please avoid personal subjective guess. A product is common with confidential docs which need NDA to be signed, but it doesn't mean this product is vulnerable, and if you are really interested with how to play with this APDU command, please contact your NXP representative for further info as mentioned in the APDU spec. 

Thanks for your patience and understanding!

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