Explanation on file format Tata-Esim PDF

Preview

Summary

asd...

Description

On the EUICC order input file 30 112318151552 001 1 893107111830421999 893107111830421999 30 is the number of EUICCs 112318151552 is the date 001 is the SR-ID(to identify the SR for future when there can be multiple SR instances) 1 is the index of the enabled profile. On the EUICC order output file: 30 112318151552 001 1 893107111830421999 893107111830421999 12345678945612345645678934523234 30 is the number of EUICCs 112318151552 is the date 001 is the SR-ID(to identify the SR for future when there can be multiple SR instances) 1 is the index of the enabled profile

In the content between input and output file, the EUICCID is added by Gemalto. On the Profile input file and output file: 00567 112318151552 30 5014 3 0 0 3 1 00567 TEA Number 112318151552 Date 30 Number of ICCIDs 5014 Electric Profile Number 3 Number of IMSIs per ICCID 0 Transport key (0 means no transport key is used) 0 OTA key (0 means no transport key is used) 3 Simtype (3 is E-Sim) 1 Step ( 1 is step 1, 2 is step 2 profile)

The input file contains the ‘non sensitive’ data that is needed for a production batch, like: ICCID, MSISDN, IMSI. The input file contains a header line with information about the batch. It contains: batch ID, timestamp, amount of SIMs in batch, Product ID, amount of IMSIs. An example: 00233 141114091800 5000 0605 2 The header line can have additional parameters indicating an index to the used Transport Keys. ‘0’ is used for no encryption and other integer values indicating the corresponding key. Typically there will be just one Transport Key per AuC platform and one per OTA platform.

The previous example of the header line will become: 00233 141114091800 5000 0605 2 1 3 For encryption of AuC parameters with the transport key with index ‘1’, and encryption of OTA parameters with key index ‘3’. 5.1.1 Format of input file data Every subsequent line in the file contains the data for each individual SIM card. Up till now the fields contain the ICCID, MSISDN1, MSISDN2, primary IMSI, IMSI 1 to a maximum of 10 and optional an EAN code (with or without check digit). The new input file format includes only the IMSI’s, not the SMSC addresses. The following line contains an example of the subscriber data in an input file (using the new format): 893107021500123456 9131637000370FFFFF FFFFFFFFFFFFFFFFFF 204070000123456 204047910123456 204070000123456

Please note that primary IMSI indicates which IMSI should be active on first use, so for a card with one IMSI it is normal to see two times the same IMSI in the input file. The output file contains the ‘sensitive’ data for the SIM, and starts with an exact copy of the header line from the input file. Further each subsequent line contains the card specific parameters: ICCID, MSISDN, IMSI, K, PIN1, PIN2, PUK1, PUK2, ADM1, KIC1, KID1, KIK1. K can be encrypted with the transport key for AuC; the first index in the header line. ADM1, KIC1, KID1, KIK1 can be encrypted with the transport for OTA; the second index in the header line. The reason for using two different transport keys is to ensure that this key never needs to be exposed outside an AuC or OTA platform. Parameters K, KIC1, KID1 and KIK1 have a length of 16 Bytes. ADM1 has a length of 8 Bytes. The encryption protocol that is used, uses a block size of 128 bits (16 Bytes). Therefore ADM1 must be padded. The padding value (for the un-encrypted ADM1) will be: 0x8000000000000000 In case the header line contains value ‘0’ (no transport key used), then the ADM1 key in the output file will also be padded with this same value. Please note that for this profile we will expect 16 as transport key identifier in the output file for both Auc and OTA keys....