Secure Personalization of Java Card Applets Using Issuer Security Domain and SCP02
The tutorial demonstrates an elegant approach to secure Java Card applet personalization by relying on the built-in security features of the Issuer Security Domain instead of custom asymmetric cryptography implementations.
Background and Problem Statement
Previous examples using ECDH for session key derivation required significant testing resources and failed to provide authentication, allowing any party knowing the elliptic curve parameters to extract secrets. The new method avoids these issues by delegating security to the GlobalPlatform card manager.
The use case involves an access control system where employee data (name, department, position, validity period) must be written or updated only by authorized parties over a protected channel. Any reader can retrieve the data, but it is returned encrypted with AES-128. The applet must securely receive and periodically update the 16-byte key throughout the card lifecycle.
Applet Implementation Details
The constructor simply allocates a 255-byte buffer for personal information. Heavy cryptographic objects such as AESKey and Cipher are instantiated after installation to avoid 6F00 errors on NXP cards during the INSTALL for install command.
The install method follows GlobalPlatform guidelines by passing the instance AID to register(). The process method handles three proprietary instructions for setting the secret key, writing personal data, and reading personal data, while unknown instructions are routed to mutual authentication.
A helper method determines whether an instruction carries command data, ensuring setIncomingAndReceive is called only when needed. Comprehensive try-catch blocks convert CryptoException reasons into informative status words instead of generic 6F00 errors.
Secure Channel Usage
The applet obtains a SecureChannel instance in select() via GPSystem.getSecureChannel and resets it in deselect(). Unknown APDUs invoke scp02.processSecurity, which handles INITIALIZE UPDATE and EXTERNAL AUTHENTICATE commands according to the negotiated security level.
The update_secret_key method calls unwrap with an adjusted length to account for the CLA offset, then verifies that the security level includes C_DECRYPTION before installing the AES key. The set_person_info method applies a lower requirement of C_MAC only.
Reading personal information simply initializes the AES cipher in encryption mode and returns the ciphertext. All operations are tested using the FunGP Python library, which supports multiple SCP02 security levels configurable at mutual authentication time.
Related articles
How to Prepare Your Website for Data Center Outages: Business Resilience Checklist
Following strikes on Yandex data centers, many businesses discovered that their sites and all backups were stored in a single location, leading to complete outages. The article provides a detailed checklist to mitigate such risks by separating critical components across different providers. Key recommendations include moving DNS to an independent provider, lowering TTL values, maintaining a live mirror site on separate hosting, and isolating corporate email. Additional steps cover local backups, monitoring, access management, and CDN usage. The guidance differentiates between virtual hosting, VPS or dedicated servers, and website builders like Tilda, while emphasizing compliance with Russian data localization laws such as 152-FZ.
How to Properly Compare CDNs: TTFB, p95 Latency, Caching, DDoS Protection and True Pricing
Selecting a CDN based solely on the number of points of presence is as unreliable as choosing a car by dashboard buttons. Networks with dozens of global PoPs may underperform for audiences concentrated in Novosibirsk or Yekaterinburg, while smaller regional providers often deliver superior peering with Russian operators. The article evaluates CDNVideo, EdgeCenter, Curator, NGENIX and Yandex Cloud CDN across verifiable features, network design, caching behavior, security controls, operations and commercial models. Performance data is separated because marketing claims cannot substitute for independent measurements from services such as CDNMON. Emphasis is placed on p95 metrics, cache hit ratios, origin shielding, raw logs and API limits rather than marketing scores. The analysis shows that no single universal ranking exists; optimal choice depends on traffic profile, audience geography, security requirements and operational workflows.
Innostage Lab Benchmarks PT NGFW 1.10.3 Performance in Eight Load Scenarios
Innostage researchers conducted extensive performance testing of PT NGFW version 1.10.3, the certified release at the time of trials. The evaluation covered TCP connection setup rates, concurrent session capacity, and throughput on a custom EMIX traffic profile with varying security modules enabled. Tests used Cisco TRex generators and a high-rule-count policy of 100,000 entries to simulate realistic enterprise conditions. Results showed the device sustaining 700,000 CPS and 6.4 million concurrent connections, matching or approaching vendor claims under HA-cluster configuration. Throughput remained above 27 Gbps even with IPS, application control, antivirus, NAT, URL filtering, and logging active. The report highlights differences in test methodology compared with vendor figures, including packet sizes and clustering setup.
Java Card Tutorial: Implementing Supplementary Security Domain to Limit ISD Privileges
A detailed technical guide demonstrates how to create a Supplementary Security Domain (SSD) on Java Card platforms to isolate applet management from the Issuer Security Domain (ISD). The approach prevents full card compromise if ISD keys are exposed by restricting SSD privileges to specific functions such as accepting extradition only from the ISD. Using the FunGP library and SCP02 protocol, the tutorial walks through installation, personalization with encrypted keys, and extradition of applets under the new domain. GlobalPlatform specifications including GP CS v2.3 and GP CIC v2.0 are followed for install parameters, privileges, and STORE DATA commands. After personalization the SSD reaches the PERSONALIZED lifecycle state, allowing secure delegation of applet control while the ISD retains overall card management rights. The method eliminates the need for custom operating systems and provides a standards-compliant way to enforce least-privilege access on smart cards.