path: root/2021/osmodevcall-sim_profile_production/osmodevcall-sim_profile_perso_production.adoc

SIM Profile, Personalization, Production
========================================
:author:	Harald Welte <laforge@osmocom.org>
:copyright:	2021 by Harald Welte (License: CC-BY-SA)
:backend:	slidy
:max-width:	45em

== Overview

What this talk is about

* How a SIM card is made
** physically / hardware
** logically / software

== SIM card basics

FIXME

== Physical Card production

== Smart Card Chip (ICC)

* contains CPU, RAM, Flash, ROM, UART
** Example: ARM SecureCore SC000 (like Cortex-M0)
* produced on wafers like any other chip

== Microconnector

* Industry term for the 6/8 contacts of a smart card
* manufactured on 35mm reel-to-reel film
* think of it as large/long flex PCB

== Module

module = microconnector + chip die

* Module combines _microconnector_ with _chip die_
* Three steps
** die bonding (fixing silicon chip die on microconnector)
** wire bonding (connect contacts with die)
** Encapsulation (some resin blob on top of bonded chip)

== Plastic Card

* Manufactured independently
* Can be PVC, ABS or other material
* High-level process:
** Plastic card poroduction
** Printing of cards
** milling of location where module is to be embedded

== Module Embedding

Glue is used to mount the _module_ in the _plastic card_

Result: Physical smart card as we know it, can be inserted into readers

== Physical Production Summary

[graphviz]
----
digraph G {
  rankdir=LR;

  {
    rank = same;
    wafer [label="Chip Wafer"];
    plastic_card [label="Plastic Card"];
    microconnector [label="Microconnector"];
  }

  die [label="Chip Die"];
  smart_card [label="Smart Card"];

  dicing [shape=square];
  module_prod [shape=square,label="Module Production\n\ndie bonding\nwire bonding\nencapsulation"];
  printing [shape=square];
  milling [shape=square];
  embedding [shape=square];

  wafer -> dicing;
  dicing -> die;
  microconnector -> module_prod;
  die -> module_prod;

  plastic_card -> printing;
  printing -> milling;

  milling -> embedding;
  module_prod -> embedding;

  embedding -> smart_card;

}
----

== Are we done yet?

Physical card has been produced.

But: Card is in Pre-Personalization stage, no software / data yet!

== Software and data on card chip

* boot loader
* operating system
* filesystem hierarchy
** which files exist at all?
** structure / size of the files
** content of the files
** access rules of the files
* applications
** can contain code
** can contain application-specific filesystem tree


== Card Operating System

* Card OS vendors develop operating systems for smart cards. All of them proprietary.

* Today, OS are often portable and support a number of different chips from different vendors

* Card OS typically licensed with a per-chip royalty

* If Java Applets are supported, another royalty to Sun/Oracle


== Card Applications

An application usually consists of the following parts

* executable code
** implements commands received e.g. via
*** commands from the phone/modem
*** wrapped/nested commands received by phone/modem from operator OTA
* file system
** structure
** content
** access control

== Card Applications on SIM

Examples of typical applications on a SIM card:

* Classic 2G SIM (TS 51.011)
* USIM (TS 31.102)
* ISIM (TS 31.103)
* OTA RAM (Remote Application Management)
* OTA RFM (Remote File Management)
* ARA-M (Android UICC Carrier Privileges)

== SIM Profile

The _SIM profile_ typically consists of

* Operating System (if card is flash and not ROM based)
* Applications (in a format that can be executed by the OS)
** typically either native or JavaCard application
* file system
** structure
** content
** access control
* non-filesystem data/config
** PIN, PUK, ADM data
** keys for AKA, OTA, SCP02


== SIM Profile creation

* vendor-specific proprietary tools
** GUI to define / edit the filesystem tree
* vendor-specific proprietary file format for editable profile

At some point, APDU scripts for card personalization are generated

* thousands of commands like
** _CREATE FILE_ (files in FS, see TS 102 222)
** _UPDATE FILE / UPDATE BINARY_ (content of files, see TS 102 221, 31.102, ...)
** _INSTALL_ (applications, see Global Platform Specs)

Alternatives

* create those thousands of commands by hand, or
* create some custom tools generating those commands


== SIM Profile representation

Aside from vendor-specific proprietary file formats, there are two standards:

* _SIMpml_ (SIM Profile Markup Language, XML based)
* _SIMalliance interoperable profile_ (ASN.1 based)

The latter is also used in the eSIM universe, where a standardized (interoperable!)
format is required, as the [e]SIM profile can now be installed in the UICC (chip)
of any vendor.

== SIMalliance interoperable format

Example snippets:

----
pe-pincodes0 ProfileElement ::= pinCodes : {
  pin-Header {
    mandated NULL,
    identification 3
  },
  pinCodes pinconfig : {
    {
      keyReference pinAppl1,
      pinValue '31323334FFFFFFFF'H,
      unblockingPINReference pukAppl1,
    },
    {
      keyReference pinAppl2,
      pinValue '3635353032303332'H,
      unblockingPINReference pukAppl2
    },
    {
      keyReference adm1,
      pinValue '3334383a3c37343e'H,
    }
  }
}
----

----
   createFCP :{
        fileDescriptor '4121'H,
      fileID '6f07'H,
      securityAttributesReferenced '06'H,
      efFileSize '09'H,
      shortEFID '38'H,
      fillFileContent : '0832141049737856F6'H
  },
----

== Now we have a profile!

So now we have

* a physical card that has been produced
* a profile that has been created

Let's bring them together!


== Personalization

Is the process of whatever is required software in terms of software/configuration

Details depend on the specific chip used

* Chip could have OS in mask ROM, or just a boot loader
** If OS not present yet, OS is installed via boot loader
* Protocols etc. highly specific to chip vendor/model
* sometimes, modules or even chip dies are already pre-programmed at an earlier stage to accelerate
  personalization


== Personalization

Often split in two steps

* Shared / Common personalization for all cards
** operating system
** applications
** filesystem structure / access control
** most filesystem content
* Card-individual _Dynamic Data_ phase
** IMSI
** PINs, PUKs
** key material (AKA, OTA)


== Factory APDU Script File Formats

No common standar / format

Every factory seems to use some custom format

In the end, they are all very simple, and consist of the following two
basic commands:

* reset the card
* send some command and expect a (possibly partially-wildcarded) status word
* some kind of template syntax for substituting the _dynamic data_


== Common Personalization

Consists of the list of hundreds to thousands of APDU commands

Can take quite some time

* slow UART for transmission
* every command commits some transaction to the filesystem

Some card OSs support the concept of an _image_.  Think of it as a full
file system dump/restore procedure that can very quickly restore the
entire content, rather than restoring each file individually.

== Dynamic Data Phase

APDU script with templates

card-individual parameters (PINs, keys, IMSI) are substituted into the
template while it is being executed

== End of Personalization

At the end of personalization, the _card life cycle state_ is changed
from _PERSONALIZATION_ to _SECURED_.  This is a one-way change in the
card OS that cannot be reversed.  

At this point, all the security mechanisms fall in place, and further
access to the card is  governed by the access control rules that have
been installed during personalization.

Whatever is not explicitly permitted in the profile is no no longer
possible.

== Laser engraving

The plastic card often receives some laser engraved writing, such as

* The card unique serial number (ICCID)
* The PIN / PUK values

This is performed at the same time as the personalization process,
when the same ICCID / PIN values are also programmed into the chip.

== We're done!

Once the card is personalized and entered the _SECURED_ life cycle
state, it is ready to be shipped to the end user.


== EOF

End of File