A new technical tutorial explains how to create a Supplementary Security Domain (SSD) on Java Card platforms, addressing the risk that full Issuer Security Domain (ISD) keys grant unrestricted control over the entire card.
The architecture places the SSD between the applet and the ISD. The ISD continues to manage card contents but loses direct interaction with the applet, which is now handled exclusively by the SSD. This design ensures that even if an attacker obtains SSD keys, privileges remain strictly limited.
The process begins with installation of the SSD instance from the package AID A0000001515350 and module AID A000000151535041. Install parameters include the tag 8102 0255 for SCP02 with configuration i=55 and the tag 8201 20 to accept extradition only from the ISD. The privilege byte is set to 80 for Security Domain rights.
After installation the domain reaches the SELECTABLE lifecycle state. Personalization follows with the INSTALL [for personalization] command and subsequent STORE DATA operations that deliver encrypted ENC, MAC and DEK keys along with their key check values, all formatted according to GP CS v2.3 section 11.11.4.
Once the SSD is in the PERSONALIZED state, an applet is installed under the ISD and then moved to the SSD using the INSTALL [for extradition] command. The resulting hierarchy shows the applet parent changed to the new SSD AID while the original package relationships remain intact.
The tutorial provides five Python scripts based on the FunGP library that automate reader initialization, mutual authentication over SCP02, SSD creation, key loading, and applet extradition, offering a reproducible reference implementation for developers working with GlobalPlatform-compliant smart cards.


