Personalization and STORE DATA

Note

GlobalPlatform "personalization" means loading data into an installed applet via INSTALL [for personalization] + STORE DATA. This is not the same as CPLC pre-perso/perso metadata (see Lifecycle management).

Overview

After an applet is installed on a card, it often needs to be provisioned with data — keys, certificates, configuration, EMV records, etc. The GlobalPlatform specification defines a two-step flow for this:

1. INSTALL [for personalization] (INS=0xE6, P1=0x20) — tells the card's security domain to prepare a specific applet instance for receiving data
2. STORE DATA (INS=0xE2) — sends the actual data blocks to the applet

The INSTALL [for personalization] step is not just a SELECT — it is a formal card management operation that may involve security checks, privilege verification, and state transitions on the card.

Tip

GP spec references: GP Card Spec 2.1.1 Section 9.5.2.3.5, GP Card Spec 2.2.1 Section 11.5.2.3.6

Personalizing an applet

Using --personalize (recommended)

The --personalize option sends INSTALL [for personalization] before the STORE DATA commands. This is the explicit, preferred way to personalize an applet:

gp --personalize D2760001240102000000000000000000 --store-data AABBCCDD

This works with all STORE DATA variants (--store-data, --store-data-chunk, --store-data-raw, --store-dgi-file).

Using --applet (legacy fallback)

For --store-data and --store-data-chunk only, --applet can be used as an alternative to --personalize — it triggers the same INSTALL [for personalization] command:

gp --applet D2760001240102000000000000000000 --store-data AABBCCDD

Important

The --applet fallback is not supported with --store-dgi-file or --store-data-raw. Use --personalize with those variants.

Without personalization step

STORE DATA can also be sent directly to the currently connected security domain, without an INSTALL [for personalization] step:

gp --store-data AABBCCDD

In this case, the data is delivered to the entity selected with --connect (or the auto-discovered ISD by default).

STORE DATA variants

--store-data <hex> (repeatable)

Sends STORE DATA to the card, automatically splitting large payloads into multiple STORE DATA commands that fit within the card's block size. Each --store-data value is sent as a separate STORE DATA sequence:

gp --personalize D276000124010200 --store-data AABB --store-data CCDD

--store-data-chunk <hex> (repeatable)

Each value becomes exactly one STORE DATA block. Multiple values are sent as a sequence with auto-managed P2 counter and last-block indicator:

gp --personalize D276000124010200 --store-data-chunk 01AABB --store-data-chunk 02CCDD

--store-data-raw <APDU> (repeatable)

Sends pre-built STORE DATA APDUs through the secure channel. P1 is preserved from the provided APDU, but P2 is auto-managed (sequential counter with last-block handling). The APDU must have INS=0xE2:

gp --personalize D276000124010200 --store-data-raw 80E2000005AABBCCDDEE

--store-dgi-file <file> (EMV personalization)

Reads DGI (Data Grouping Identifier) blocks from a file and sends them as STORE DATA commands. Supports encrypted DGI blocks with on-the-fly DEK encryption:

gp --personalize D276000124010200 --store-dgi-file perso.dgis

For DGI blocks that require encryption, use --dgi-padded and --dgi-unpadded to specify which DGI tags need padding before encryption and which do not:

gp --personalize D276000124010200 --store-dgi-file perso.dgis --dgi-padded 8000,8010 --dgi-unpadded 9000

Quick reference

Variant	Splitting	P1/P2 control	Encryption	--applet fallback
--store-data	Auto-split	Managed	No	Yes
--store-data-chunk	One chunk per block	Managed	No	Yes
--store-data-raw	User-provided APDUs	P1 preserved, P2 managed	No	No
--store-dgi-file	From DGI file	Managed	DEK via --dgi-padded/--dgi-unpadded	No