SIM profile/perso/production slides

2 files changed, 342 insertions, 0 deletions

diff --git a/2021/osmodevcall-sim_profile_production/osmodevcall-sim_profile_perso_production.adoc b/2021/osmodevcall-sim_profile_production/osmodevcall-sim_profile_perso_production.adoc
new file mode 100644
index 0000000..439fd16
--- /dev/null
+++ b/2021/osmodevcall-sim_profile_production/osmodevcall-sim_profile_perso_production.adoc
@@ -0,0 +1,342 @@
+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
diff --git a/2021/osmodevcall-sim_profile_production/sim-profile-production.vym b/2021/osmodevcall-sim_profile_production/sim-profile-production.vym
new file mode 100644
index 0000000..c18915c
--- /dev/null
+++ b/2021/osmodevcall-sim_profile_production/sim-profile-production.vym