Applet 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? Virtual test Re: Applet 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.
Kan_Li_0-1784275947082.png
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. ------------------------------------------------------------------------------- Re: Applet Hi Kan, Thank you for the detailed answers — very helpful. I will mark the post as correct. Following up on question 1: I would like to request the documents you mentioned (custom Java Card applet development path for the SE051P — SDK, tools, Java Card / GlobalPlatform versions, and applet provisioning) via the secure file channel. Could you please let me know the exact procedure? Specifically: 1. How do I access the secure file channel — should I open a private support case on the NXP support portal linked to this community account, or is there another route? 2. Which of these documents are available before an NDA is in place, and which ones require the NDA / local representative path you mentioned in question 2? My goal at this stage is to review the development path documentation to plan the prototype phase; the NDA/MOQ discussion with the local representative would follow. Thank you again, aaschi
View full article
