This command is only available when the applet is in pre-initialized state and successful execution brings the applet to the initialized state. It stores the user authentication credentials — nothing more. Creating a wallet is a separate step, done with LOAD KEY or GENERATE KEY.
The payload is the concatenation of:
| Field | Size | Required |
|---|---|---|
| PIN | 6 digits | yes |
| PUK | 12 digits | yes |
| Max PIN retries | 1 byte | no, default 3 |
| Max PUK retries | 1 byte | no, default 5 |
| Duress PIN | 6 digits | no, defaults to the first half of the PUK |
Retry limits are validated against the ranges 2–10 for the PIN and 3–12 for the PUK. The duress PIN works as described in VERIFY PIN.
The payload never travels in the clear. The client generates a throwaway secp256k1 key pair, performs EC-DH with the card and encrypts the payload with AES-CBC using ISO/IEC 9797-1 Method 2 padding and a random IV. The secure channel is then established normally.
Before 4.0 the one-shot encryption key was derived from the card's ephemeral public key returned by SELECT; since 4.0 SELECT returns the identity certificate instead and the initialization payload is carried over the same secure channel used by every other command. The command is also available before the card holds a PIN, which is what makes the "is this card initialized?" check in the SELECT status byte useful.
After successful execution this command cannot be executed again.