Secure Elements & Java Card
A Secure Element is a tamper-resistant chip that runs a small set of vetted applications in isolation from the device's main processor, with keys generated on-chip that are designed never to leave it. AmbiSecure implements cryptographic isolation, hardware-backed identity, and embedded trust anchors inside Secure Elements and eUICC silicon using Java Card applets.
A controlled environment where keys live and computation happens.
A Secure Element is not "a chip with crypto" — it's a controlled execution environment with documented physical and logical resistance properties, separate from the device's main application processor. Sensitive operations happen inside it. Keys are generated, used, and never exposed in a usable form to the outside. Java Card is the most common way to write portable applets that run inside that environment.
AmbiSecure designs the applet layer that turns a Secure Element into a useful identity and security primitive for connected products — and connects it cleanly to the surrounding firmware, operating system, and provisioning workflows.
Application code, firmware, OS
Java Card VM · applets · key store
Where applet engineering pays off
Identity applets
Per-device identity, key custody, and signed assertion logic that lives entirely inside the Secure Element.
Crypto operations
Signing, key wrapping, and verification flows that never expose private material outside the SE.
Attestation
Applets that produce verifiable assertions about device, firmware, or configuration state.
Provisioning logic
Controlled paths for receiving, storing, and using credential material under operator-style processes.
Secure messaging
Authenticated, confidential channels between SE applet and counterpart components.
Lifecycle
Applet states aligned with manufacturing, deployment, in-service, and end-of-life realities.
Designed to be reviewed, not just used.
Secure Element applets earn their trust by being inspectable. We document trust boundaries, key flows, applet states, and the rationale behind cryptographic choices. An operator security team or third-party reviewer should be able to read our material, walk the code, and form their own opinion.
- Documented applet state machines
- Explicit listing of keys, where they live, and what they sign
- Failure-mode analysis for typical deployment scenarios
- Test vectors and harness output suitable for review
Articles
Want to walk the applet design?
We're happy to share documentation and walk a security reviewer through trust boundaries, applet states, and assumptions.
Frequently asked questions
What is a Secure Element?
A Secure Element is a tamper-resistant chip that stores keys and runs a small set of vetted applications in isolation from the device's main processor. Keys generated inside it are designed never to leave, so cryptographic operations happen on-chip rather than in general-purpose memory.
What does Java Card add on top of the Secure Element?
Java Card is the runtime that lets identity, key custody, and cryptographic logic be delivered as applets on that hardware. It gives each applet an isolation boundary — a firewall between co-resident applications — while keeping the code portable across compliant silicon.
Why run identity in an applet rather than in device firmware?
Firmware is copyable and updatable in the field; an applet on a Secure Element holds its keys behind a hardware boundary and a controlled lifecycle. That separation is what lets an identity survive review and resist extraction.
Are these applets designed to be reviewed?
Yes. Applet behaviour, the key inventory, and the trust boundaries are documented so a security team can read them before any code is exchanged. The design goal is to be reviewed, not merely used.
How is a Java Card applet loaded and managed?
Through GlobalPlatform card management: applets are loaded, instantiated, and lifecycle-managed inside security domains, with key custody kept on-chip.