Hi, please. Can anyone help me?
1. What is the practical development path to build and load a custom Java Card applet on the SE051P (which SDK, tools, and Java Card / GlobalPlatform version)? Is custom-applet provisioning done at the factory (pre-loaded by NXP or a partner), or can it be done post-issuance in the field via a GlobalPlatform secure channel, and what key-management requirements apply?
2. Are there licensing, NDA, or partnership requirements — or a minimum order quantity — to obtain SE051P parts together with the ability to develop and provision custom applets?
B. Coexistence of payment and custom logic (one vs. two secure elements)
3. Can a single JCOP Pay (payment) platform host, simultaneously, an EMVCo-certified payment applet AND a separate custom Java Card applet with independent application logic? Or does EMVCo certification require the chip to run only the payment applet — meaning a separate secure element would be required for the custom logic?
4. If coexistence on a single chip is possible, does loading a custom applet affect or invalidate the EMVCo certification of the payment applet?
C. Monotonic counter and crypto available to a custom applet (SE051P)
5. Is the native monotonic Counter secure-object accessible from a custom applet via the Java Card API, or only through the pre-installed IoT applet interface?
6. Which signature algorithms and ECC curves are available to a custom applet on the SE051P (e.g., ECDSA P-256/P-384, Ed25519)? Is internal signing of a value stored on-chip (as with the POLICY_OBJ_INTERNAL_SIGN mechanism) available from a custom applet as well?
D. Power for a coin-cell (CR2032) device
7. What is the typical duration (in milliseconds) of a single ECDSA P-256 signature operation, and what is the idle/standby current of the SE051P outside active crypto operations? (So that energy per operation and standby drain can be estimated.)
8. For a part powered by a high-impedance source such as a CR2032 coin cell, does NXP recommend a specific decoupling capacitor or buffer to handle the 16.5 mA peak current during a crypto operation?
9. In the SE051P, can the contactless interface operate RF-powered (drawing energy from the reader field) for custom-applet operations, or does custom on-chip logic require external power (e.g., a battery)? If RF-powered operation is possible, are there constraints — under field power alone — on operations such as ECDSA signing, signature verification, monotonic-counter increment, secure-object update, or other non-volatile memory writes?
Hi @aaschi ,
Thanks for the reaching out! Please have my comments as below:
1. What is the practical development path to build and load a custom Java Card applet on the SE051P (which SDK, tools, and Java Card / GlobalPlatform version)? Is custom-applet provisioning done at the factory (pre-loaded by NXP or a partner), or can it be done post-issuance in the field via a GlobalPlatform secure channel, and what key-management requirements apply? // We provide docs on these topics, please request them via the secure file channel. please refer to the following for more details.
2. Are there licensing, NDA, or partnership requirements — or a minimum order quantity — to obtain SE051P parts together with the ability to develop and provision custom applets? // Yes, NDA is needed, and MOQ as well. please check with your local NXP representative for more details.
B. Coexistence of payment and custom logic (one vs. two secure elements)
3. Can a single JCOP Pay (payment) platform host, simultaneously, an EMVCo-certified payment applet AND a separate custom Java Card applet with independent application logic? Or does EMVCo certification require the chip to run only the payment applet — meaning a separate secure element would be required for the custom logic?// No, you have to use two secure elements — one certified payment SE and one SE051P/custom SE for proprietary logic.
4. If coexistence on a single chip is possible, does loading a custom applet affect or invalidate the EMVCo certification of the payment applet?// No, it is not possible.
C. Monotonic counter and crypto available to a custom applet (SE051P)//The SE05x IoT-applet documentation supports monotonic counter secure objects, so from hardware perspective, it should support by SE051P as well, but it depends on your custom applet implementation.
5. Is the native monotonic Counter secure-object accessible from a custom applet via the Java Card API, or only through the pre-installed IoT applet interface? // you can not install the SE05x pre-installed IoT applet on SE051P, you have to develop your own custom applet.
6. Which signature algorithms and ECC curves are available to a custom applet on the SE051P (e.g., ECDSA P-256/P-384, Ed25519)? Is internal signing of a value stored on-chip (as with the POLICY_OBJ_INTERNAL_SIGN mechanism) available from a custom applet as well?
// The SE05x IoT applet supports a broad set of algorithms and curves so SE051P can support but it depends on your custom applet implementation
D. Power for a coin-cell (CR2032) device
7. What is the typical duration (in milliseconds) of a single ECDSA P-256 signature operation, and what is the idle/standby current of the SE051P outside active crypto operations? (So that energy per operation and standby drain can be estimated.)//ECDSA P-256 verification is documented as <55 ms; signing timing was not found. Active asymmetric crypto current is up to 16.5 mA. Such info is from The SE05x IoT applet, for a custom applet, it depends on your own implementation.
8. For a part powered by a high-impedance source such as a CR2032 coin cell, does NXP recommend a specific decoupling capacitor or buffer to handle the 16.5 mA peak current during a crypto operation?//No specific CR2032 buffer capacitor value was found; design around 16.5 mA peak plus operation time and cell ESR.
9. In the SE051P, can the contactless interface operate RF-powered (drawing energy from the reader field) for custom-applet operations, or does custom on-chip logic require external power (e.g., a battery)? If RF-powered operation is possible, are there constraints — under field power alone — on operations such as ECDSA signing, signature verification, monotonic-counter increment, secure-object update, or other non-volatile memory writes?//RF-powered SE051 operation is supported, but RF-only support for custom applet crypto/NVM updates must be confirmed and tested.
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.
-------------------------------------------------------------------------------