diff options
Diffstat (limited to '2021/osmodevcall-sim_profile_production')
| -rw-r--r-- | 2021/osmodevcall-sim_profile_production/osmodevcall-sim_profile_perso_production.adoc | 342 | ||||
| -rw-r--r-- | 2021/osmodevcall-sim_profile_production/sim-profile-production.vym | bin | 0 -> 2451 bytes |
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 Binary files differnew file mode 100644 index 0000000..c18915c --- /dev/null +++ b/2021/osmodevcall-sim_profile_production/sim-profile-production.vym |