SIM profile/perso/production slides
This commit is contained in:
parent
5d0629e999
commit
64fe898535
|
|
@ -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
|
||||
Binary file not shown.
Loading…
Reference in New Issue