Personalizing test (U)SIM cards for different customers, a new challenge arised where a customer actually wanted different serial numbers on the cards. Our test cards have the same ICCID number on all cards. Anyway, this is handled by the file 2F E2 - IC Card Identifier, under MF. This file contains the IC card's serial number coded on 10 bytes and allows the operator to identify the card unambiguously for billing purposes.
The coding of the serial number for cards of Phase2/2+ onwards it is defined in ITU-T E118. CCITT E118 specifies a Serial Number length between 0 and 18 digits plus an extra byte containing a checksum written in its least significant (that is, rightmost) digit. The checksum is always stored in this byte whatever the length of the serial number (if the serial number is shorter than 18 digits it is padded (One or more bits appended to a message in order to ensure that it contains the required number of bits or bytes.) with Fh up to digit 20. Coding the serial number on 20 digits overwrites the checksum. Some operators today use 19 digits followed by the checksum without any padding.
It's composed of the following subparts:
– Major Industry Identifier (MII);
– country code;
– issuer identifier;
– individual account identification number;
– parity check digit
Now, using a tool like Gemalto Card Admin I can automatically get the correct checksum for the ICCID I choose to enter. But in our automated processes where we use APDU scripts, I needed to know how to calculate this checksum so it could be automatically appended to the serial number and the card correctly personalised.
I found out that the Luhn algorithm or Luhn formula, also known as the "modulus 10" or "mod 10" algorithm, is used to calculate the checksum.
So very simply, assume an example of a serial number "896588081210001114" that will have a check digit added, making it of the form 896588081210001114x:
| ICCID | 8 | 9 | 6 | 5 | 8 | 8 | 0 | 8 | 1 | 2 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 4 | |
| Double every other | 8 | 18 | 6 | 10 | 8 | 16 | 0 | 16 | 1 | 4 | 1 | 0 | 0 | 0 | 1 | 2 | 1 | 8 | |
| example: 18=>8+1=9 | 8 | 9 | 6 | 1 | 8 | 7 | 0 | 7 | 1 | 4 | 1 | 0 | 0 | 0 | 1 | 2 | 1 | 8 | Sum of digits= 64 |
First double every other number starting from the end. Add the digits if >1. For example 18=1+8=9
The check digit (x) is obtained by computing the sum of digits then computing 9 times that value modulo 10 (so that's: (67 * 9 mod 10)). In layman's terms:
- Compute the sum of the digits (64).
- Multiply by 9 (576).
- Take the last digit (6).
- The result is your check digit.
So in this case the complete ICCID is 8965880812100011146
Example:
-The first two digits are fixed and are the Industry Identifier. “89” refers to the Telecommunications Industry.
-The next two or three digits refer to the Mobile Country Code (MCC) as defined by ITU-T recommendation E.164. “310” refers to the United States.
-The next one to four digits refer to the Mobile Network Code (MNC). This is a fixed number for a country or world zone. “410” refers to the operator, AT&T Mobility.
-The next two digits, “10,” pertain to the Home Location Register.
- Individual Account Information - is variable in length:
-The next nine digits, “654378930” represent the individual account identification number. Every number under one IIN has the same number of digits.
- Check Digit – the last digit, “1,” is computed from the other 18 digits using the Luhn algorithm.