Smart card operating systems

Transcription

1 Part 3 : Smart card operating systems

2 Smart Card Operating System (COS) Why a COS? Main OS families ISO/IEC 7816 communication protocols data organization (file structure) commands Example: WG10-compliant IEP The trend towards Open OS Contactless smart cards OS constraints Security

3 An Operating System on a Chip What is a COS? A software specific to each smart card manufacturer Loaded and protected in the chip ROM by the chip manufacturer a MASK is created A mask contains general-purpose core routines which serve as an interface with a micro-controller Special-purpose application programs are stored in EEPROM. They are be built on top of core routines using them as necessary ROM OS Chip Organization CPU SECURITY R A M E E P R O M E P R O M Designed by Gemplus Loaded by chip manufacturers

4 Card OS role Operating systems are the core of smart cards An operating system handles : File management Security (managing and executing cryptographic algorithms) I/O (transferring data to and from the smart cards) Controlling the execution of commands Applications API, Similar to the OS of PCs with less memory, more security, and no user (human) interface

5 Command processing The smart card receives each command via the serial I/O interface The I/O manager executes error detection mechanism The I/O manager is fully independent of other, higher layers After a command has been completely received without error, the secure messaging manager must decrypt the message and test its integrity If the integrity check is OK, the command interpreter decodes the command. If not possible, the return code manager is called. If decoding is OK, the logical channel manager determines which channel has been selected, switches over to its state and calls the state machine

6 Command processing (cont) The state machines define instruction sequences. They become active when in first instruction of a sequence has been sent to a card. The state machine checks whether the command and accompanying parameters are actually permitted in the current state of a Smart Card. If yes, the actual code of the application command that carries out the processing of the received command is executed. If the command is prohibited in a current state, or if its parameters are not allowed, the terminal receives a message to this effect via the return code manager and I/O manager.

7 Command processing (cont) If it is necessary to access a file while processing a command, the file manager is called. It converts a logical address of the file into its physical address on a chip It also monitors all addresses with regards to region boundaries It tests the access conditions for the file in question The file manager itself utilizes a lower-level memory manager which is responsible for the entire management of the EEPROM. Only the memory manager works with physical addresses, which increases security and portability of OS.

8 Command processing (cont) The return code manager is responsible for generating an answer code. It produces a complete answer for the program segment which was called and sends it back to the terminal via I/O manager. May be different return code managers for different applications. Usually, there is a dedicated library of cryptographic functions which serves all other modules. It is separate from the rest of the system.

9 To add new features A FILTER adds new features to an existing COS Software routine stored in the EEPROM Only accessible by the COS Transition to a new product Applets are coming up Filter Chip Organization ROM COS CPU SECURITY R A M E E P R O M

10 Main COS Families SIM (Subscriber ID module) cards GSM (TE9), 11.14, OTA Debit/Credit EMV, VISA Electronic Purse WG10, MPCOS, CEPS DataBase Loyalty Simple with counters & rules Public Key for IT Access (GemSafe)

11 Major standards ISO 7810 : plastic cards, dimensions ISO 7811 parts 1-6 : ID Cards ISO 7816 parts 1-8 : contact integrated circuit cards ISO parts 1-4 : close coupling cards ISO parts 1-4 : remote coupling cards US standards : FIPS-46 : Data encryption standards FIPS-81 : DES modes of operation FIPS : secure hash standards FIPS-186 : Digital Signature Standards GSM (ETSI for 3G, EMV (Europay, Mastercard, VISA), PC/SC, CCITT...

12 Standards ISO7816 for Contact Cards ISO14443 for contactless cards : Card Body : Electrical Module : Electrical Signals & Protocols : Inter-Industry Commands : Database : Security mechanisms (Completed) Card Body (Approved CD) RF power & signal interface (1st CD) Initialization & AntiCollision (Proposals) Protocol

13 The ISO

14 Includes Transmission Protocol The ISO describes The way the card and the reader communicate Two communication protocols are standardized T=0 asynchronous, half-duplex, byte oriented, inverse convention, parity bit is even T=1 asynchronous, half-duplex, block oriented, with enhanced security T=0 T=1 Almost all currently available cards follow T=0

15 ...Includes File Architecture MF DF DF DF EF EF EF EF EF EF EF The card is organized into files. MF (Master File) : root of the structure. Seen as a main directory. DF (Dedicated File) : seen as a directory. Each DF behaves like an independent card (contains files related to a single application). EF (Elementary File) contains actual data Working EF (application data that must be read or written from the terminal, i.e., data for external world) Internal EF (data for the operating system, secret keys or program code. Access to data is protected by the COS.)

16 File architecture (cont) MF DF DF DF EF EF EF EF EF EF EF MF is present in all Smart Cards. MF is implicitly selected after the Smart Card is reset. It contains all other directories and files. DF is a directory in which other files which logically belong together (DF and EF) are grouped. EF contains data that are needed for applications. EF always have an internal structure.

17 ...Includes Command sets File management commands read, write, update read binary, update binary read record, update record, append record select file Authentication commands external authenticate, internal authenticate, get challenge... Access condition management verify code Personalization commands...

18 Transmission protocols First step : how to communicate with a smart card?

19 Communication Protocols Standards Overview Protocol application layer APDU (application protocol data unit) exchange A software data container that is used to package the data so that they can be exchanged between a Smart Card and a terminal. ATR (answer to reset) A sequence of bytes sent by a Smart Card in response to a hardware reset. Includes various parameters relating to a transmission protocol

20 Contact Communication Protocols T=0 (ISO7816-4) Byte protocol Mono channel Get Response required > 95% of smart cards T=1 (ISO7816-4) Block protocol Partially capable of multi-node Complex Interoperability issue due to complexity (error cases)

21 T=0 T=0 is byte-oriented The smallest unit processed by the protocol is a single byte. The structure of commands for T=0 is: Header (always), DataPart (optional). Header = CLA, INS, P1, P2, P3 (class byte, command, parameters). P3 provides the length of either a command, or data, or response. If error is detected, only one byte is retransmitted. Asynchronous

22 T=1 Asynchronous Half-Duplex Block Transmission Protocol Frame Format: NAD (assigned) PCB LEN DATA CRC-1 CRC-2 Parameters: NAD (node address) contains blocks source and destination addresses Timing: BGT (block guard time), BWT (block waiting time), CWT (character waiting time), Sizes: LEN (length) IFS(C/D) EDC: LRC (longitudinal redundancy check), CRC (cyclic redundancy check) PCB (protocol control byte): I-Block (information block), S-Block (system block) or R-Block (reception acknowledgement block)

23 Command: Protocol Application Layer APDU Format Header field Body field CLA INS P1 P2 Lc Data Field Le 1rst part (mandatory) 2nd part (optional) CLA: Class of the Command INS: Instruction Code P1, P2: Command parameters Lc: Length of subsequent data field Le: Expected length of data to be returned Response: Data Field SW1 SW2 1rst part (optional) 2nd part (mandatory) SW1: Status Word1 = Command Processing Status SW2: Status Word2 = Command Processing Qualification

24 APDU Exchange (1/2) Case1: No input / No output CLA INS P1 P SW1 SW2 Case 2 : No input / Output of expected length CLA INS P1 P Le Data Field SW1 SW2 Case 3 : Input / No output CLA INS P1 P2 Lc Data Field SW1 SW2

25 APDU Exchange (2/2) Case 4 : Input / Output of expected length CLA INS P1 P2 Lc Data Field Le Data Field SW1 SW2 In this case, TPDU is different for T=0 or T=1. For T=0: command TPDU CLA INS P1 P2 P3=Lc Data Field if the command is not accepted, the response TPDU is the following (SW1=6Xh except 61h) response TPDU (XX) SW1 SW2 if no XX and SW1-SW2 = 9000h, then PCD sends a GET_RESPONSE command (INS=C0h): command TPDU CLA C0h P1 P2 P3=Le response TPDU data (Le bytes) SW1 SW2 if XX field is present and SW1 = 61XXh, then PCD issues a GET_RESPONSE with Le=XXh command TPDU CLA C0h P1 P2 P3=Le response TPDU Data Field SW1 SW2

26 ATR Example Character Value Description TS 3Bh Direct convention T0 6xh TB1 and TC1 present, x historical characters (default: x=8) TB1 00h Vpp not required TC1 00h No extra guardtime required T1-T8 Historical characters (8 bytes) T1 80h Status information is contained in an optional TLV object T2 66h Tag: 6 (Pre-issuing data), length: 6 bytes T3 xx OS family name (Gemplus proprietary coding) T4 xx Product name (Gemplus proprietary coding) T5 xx OS version (Gemplus proprietary coding) T6 xx Program version (Gemplus proprietary coding) T7 xx Chip reference (Gemplus proprietary coding) T8 xx Card life status byte (see below) T9..T15 xx Optional historical characters in ATR file (see below)

27 EEPROM Memory Organization

28 How EEPROM is partitioned by a COS Fabrication data Simiconductor manufacturer Production facility CSN bytes (WORM access) OPERATING SYSTEM Contains tables and OS pointers which combine with ROM program to yied the complete COS Protected by EDC APPLICATION PROGRAMS Application-specific algoritms that are too large to be in ROM or should not be in ROM Protected by EDC FILE REGION Contains all of the file structures. MF region DF1 region DF2 region. Free memory management in future Has strong file-oriented protection. FREE MEMORY

29 ISO Data File Structures Root file : MF (Master File) Application directory: DF (Dedicated File) EF (Elementary Files) of different types: Working EF may have the following types: 4Transparent EF 4Linear Fixed Record EF 4Variable Record EF 4Cyclic EF System Files (Proprietary) 4Response Files, File structures 4Key Files, Code Files (with ratification counter...) 4Transaction Counter files... 4These files are managed fully transparently by the COS

30 Transparent File Transparent files have no structure. Often referred to as a binary or amorphous structure The data contained in the file can be accessed by reading or writing in bytes or in blocks, with the use of offset value. length offset data The minimum size of a file is one byte, maximum is not specified. The maximum number of bytes that can be read in a short format is 255; in long format 65,536. The maximum offset value is 32,767. Therefore, the maximum length is 65,795 bytes or 98,303 bytes Commands: READ BINARY, WRITE BINARY, UPDATE BINARY

31 Linear Fixed Record File Structure Linear Fixed Record EF is based on linking fixed-length records. A record consists of a series of individual bytes. Individual record within this data structure can be freely accessed. The smallest unit of access is record. Commands: READ RECORD, WRITE RECORD, UPDATE RECORD The length of a single record is determined by the access commands, it can range from 1 to 254 bytes. But all records have the same length! Byte number Record number The first is always 1 Up to FE or m

32 Linear Variable File Structure Linear Variable File structure is used to save memory when the records have highly variable lengths and is based on linking variable-length records. A record consists of a series of individual bytes. Individual record within this data structure can be freely accessed. The smallest unit of access is record. Commands: READ RECORD, WRITE RECORD, UPDATE RECORD The length of a single record is determined by the access commands, it can range from 1 to 254 bytes. Records have variable length!

33 Cyclic File Structure Cyclic File structure is based on the linear fixed-length file structure. All records have the same length! A record consists of a series of individual bytes. The number and size are analogous to the linear fixed-length file structure. In addition, the EF contains a pointer that always indicates the record that was last written. This record is always numbered 1. If the pointer reaches the last record in EF, it is automatically set by OS to point to the first record when the next access occurs. This structure is typically used for log files within the Smart card in which the oldest entry is always overwritten by a new entry.

34 The Multi-Application Concept Root E-Purse Data File security and data management specific to each application Example Data File Data File... Loyalty...

35 Data Files There are different file structures adapted to different needs Security files : for secret codes and keys Purse file : for electronic money Loyalty counter... Root Purse application Loyalty application Purse File Identity File Key File Secret Code File

36 Access Conditions Access conditions define rights that must be granted before actions can be performed on files All files have information that regulates access to them encoded in the file header Access conditions are defined when the file is created; they depend on the type of the file For the MF and DF s the access conditions are related to creation of new files For the EF s the access conditions are related to data access (read or write privileges).

37 Access Conditions (cont) Command-oriented access conditions define allowed command for the access in question For DF s: specify the conditions under which specific commands can be executed within the given directory Create, Delete Files, Register... For EF s: regulate all possible types of access to ES s. The number of access commands varies, and may include APPEND, DELETE FILE; INVALIDATE, READ/SEAK, LOCK, Dedicated File Create EFs EF #1 EF #2 EF #3 Read Write Update

38 Access Condition Example 1/2 Read OK EF Identity File Access Conditions Read : Free Update : SC#2 Access conditions are specific to each file

39 Access Condition Example 2/2 Update!!NOT OK!! AC not fulfilled SC#2 OK!! EF Identity File Access Conditions Read : Free Update : SC#2 Update OK!! Access conditions are checked by the OS

40 Each file is made of File descriptor (header) File Organization Contains all information for file & security management 4file name (e.g., FID = 0001 ) 4File type (e.g., FF) 4File structure (e.g., linear fixed) and size (e.g., 3 records of 5 bytes) 4Access conditions (e.g., READ = after PIN code was entered) 4Link to the file tree (e.g., directly under MF) File header can contain special attributes, such as high update activity, WORM or EDC protection, file manager support File body Contains the data stored in the EF AC Descriptor Body

41 File Identifier The OS enables data access by file identifier (logical name) instead of physical memory address Every file has 2-byte FID which is used to select the file. File creation order has no importance to the application EEPROM MF 3F 00 DF DF EF File ID

42 Example : WG10 E-purse E files

43 Example: WG10 IEP Files (1/5) IEP Information EF: File ID 0011h File type Transparent File size 22 bytes Bytes Description Data element Length (bytes) 1-3 Purse Provider Identifier PP IEP IEP Identifier IEP Expiry date DEXP IEP Activation date DACT IEP Deactivation date DDEA IEP 3 18 Authentication mode AM IEP Application Profile AP IEP IEP option bytes (*) OPT IEP Discretionary Data (ignored by the OS) DD var IEP : Inter-sector Electronic Purse

44 Example: WG10 IEP Files (2/5) IEP Key Information EF: File ID 0012h File type Linear fixed Record Length 2 bytes Bytes Description Data element Length (bytes) 1 Algorithm Identifier ALG IEP 1 2 Key version VK IEP Discretionary Data (ignored by the OS) DD var IEP Balance EF: File ID 0013h File type Transparent File size 11 bytes Bytes Description Data element Length (bytes) 1-4 IEP Balance BAL IEP Currency Code CURR IEP Maximum Balance BALmax IEP Discretionary Data (ignored by the OS) DD var

45 Example: WG10 IEP Files (3/5) Load Log EF (LLOG): File ID 0014h File type Cyclic Record length 15 bytes Bytes Description Data element Length (bytes) 1 Transaction type TRT Transaction number NT IEP IEP balance BALIEP Amount received from LDA M LDA PPSAM identifier PPSAM Discretionary Data (optional) DD up to 8

46 Example: WG10 IEP Files (4/5) Purchase Log EF (PLOG): File ID 0015h File type Cyclic Record length 22 bytes Bytes Description Data element Length (bytes) 1 Transaction type TRT IEP transaction number NT IEP Total amount of the transaction MTOTIEP IEP balance BALIEP Currency code CURR IEP PSAM identifier PSAM PSAM transaction number or Discretionary NTPSAM or 4 Data (mandatory) DD Discretionary Data (optional) DD up to 4

47 Example: WG10 IEP Files (5/5) Currency Conversion Log EF (CCLOG): File ID '0017' File type Cyclic Record length 21 bytes Bytes Description Data element Length (bytes) 1 Transaction type TRT IEP transaction number NT IEP Balance of the IEP (old value) BAL IEP (old) Currency Code (old value) CURR IEP (old) Balance of the IEP (new value) BAL IEP (new) Currency Code (new value) CURR IEP (new) PPSAM Identifier PPSAM Discretionary Data (optional) DD up to 8

48

49 ISO Command Set Read Binary Read Record Write Binary Write Record Update Binary Update Record Erase Binary Log Record Get Data Put Data (TLV) Select File Verify Internal Authenticate External Authenticate Manage Channel Get Response ATR APDU command format

50 Commands: Example (1/3) Command CLA INS P1 P2 Lc Le Select File 00h A4h 00h Child EF, using File Identifier 02h 02h 0Ch DF or MF, using DF Name 04h var var Read Binary 00h B0h ofs var Direct Selection ofs Implicit Selection sfi Update Binary (Standard) 00h D6h ofs var Direct Selection ofs Implicit Selection sfi Read Record 00h B2h rec var Direct Selection 04h Implicit Selection sfi

51 Commands: Example (2/3) Create File (Standard) 80h E0h 00h 00h var Verify Secret Code 00h 20h 00h 00h Present a Secret Code 08h Read the number of Retries Internal Authenticate 00h 88h 00h 08h 0Ah Global level key/transaction number 00h Local level key/transaction number 80h Set Access Conditions (Standard) 80h 16h AC Current EF, AC1 (Update) 00h Current EF, AC2 (Read) 01h Current DF, AC1 (Update) 02h Current DF, AC2 (Tamperproof) 03h

52 Commands: Example (3/3) Secure Messaging Command CLA INS P1 P2 Lc Le Update Binary (Secure Messaging) 04h D6h ofs var 03h Direct Selection ofs Implicit Selection sfi Update Record (Secure Messaging) 04h DCh rec var 03h Direct Selection 04h Implicit Selection sfi Append Record (Secure Messaging) 04h E2h rec var 03h Direct Selection 00h Implicit Selection sfi Create File (Secure Messaging) 84h E0h 00h 00h var 03h Set Access Conditions (Secure Messaging) 84h 16h ac 03h 03h Current EF, AC1 (Update) 00h Current EF, AC2 (Read) 01h Current DF, AC1 (Update) 02h Current DF, AC2 (Tamperproof) 03h

53 ISO7816-4: Card Responses SW1 - SW2 Process Completed Process Aborted Warnings Normal Execution Checking '62 XX' '63 XX' '90 00' '67 XX -' '64 XX' '65 XX' '61 00' '6F XX'

54 Today's Multi-application Card Example PSE DIR EF ADF 1 ADF 2 ADF3 Access Control AEF AEF AEF AEF AEF AEF AEF ISO Data Files Dedicated Payment Function in OS Dedicated Data File Loyalty ISO Data Files Generic Access functions in read, Update and Write Cryptographic security Access in read only

55 Evolution of the Smart Card Technology

56 Multi-application COS Multi-applications are reality one exe code + multiple file systems ISO FILE SYSTEM PSE Application Data 1 Application Data 2 Application Data 3 DIR EF ADF 1 ADF 2 ADF3 AEF AEF AEF AEF AEF AEF AEF Operating S. Chip Resources EXECUTABLE

57 yesterday Evolution of the Smart Card Mono-application cards Dedicated OS All the benefits of smart cards Optimized chip size/ cost effective cards Hard business case limited marketing tool very limited flexibility for scheme evolutions Technology today Multi-application cards Multi-use OS facilitate the business case new valuable services to customers Scheme finalized before issuance limited flexibility for evolutions tomorrow Multi-application platforms Open OS very flexible platforms can support new applications after issuance of the card No infrastructure upgrade not available as of today for operation

58 Multi-application in the future: Open Operating Systems

59 Requirements for an Open Operating System To Add new functionalities during life of the card To Keep or improve traditional level of security in each application Reduce the development cycle for applications by offering Standard Application Programming Interface and toolboxes Authorize third parties to develop applications Use a large-base of developers and provide them access to easy to use language and tools

60 Requirements for an Open Operating System Provide chip independence among multiple hardware targets (chips) Write Siemens Thomson Motorola Hitachi Provide isolation and separation between Multiple Applications and System

61 What is an Open Operating System? Application Data 1 Application Data 2 Application Data 3 Operating S. Chip Resources Traditional OS Application... Application c API Application b Virtual Machine Operating System (OS) Chip Resources Open OS Application a

62 What is an Application in a Open OS Card? FILE SYSTEM PSE DIR EF AEF AEF AEF ADF 1 = Application a EXECUTABLE

63 Java Card Architecture - On-Card components Java Language Card Executive GEM GEM WG10 WG10 MPCOS GSM /98 APIs Assembler Virtual Machine Native Functions & System Resources Hardware

64 OS development How does it work inside?

65 OS development Tools : emulators, simulators user s guide, technical support Detailed chip specifications OS design / development Qualification unitary tests normal execution full qualification acceptance tests

66 OS processing Data logical access Data processing Back-up management single EEPROM update multiple EEPROM update (indivisibility) anti-stress nested backup... Security checks Context verifications Security sensors Protocol processing I/O

67 OS Command Processing Examples of verifications done before command processing: Correct TPDU format Correct Le/Lc according to command Correct P1/P2 according to command Proper EF type for the command Proper DF if specific (IEP DF,...) Command is allowed according to the current state Data necessary for the command is not corrupted IEP is active and not deactivated The file descriptor integrity File access conditions...

68 Laboratory 2 (1/2) Describe microprocessor architecture. Different applications have varying proportion of different memory types. One can say that cards are divided into applications according to these ratios, as well as by the functions built into the mask. Give characteristics of different memory types and what they are used for. Volatile vs. non-volatile memory. In what ratio (only in terms large or small ) these memories will be used for following: Cards storing health records Cryptographic cards for public key cryptography New generation of security modules for mobile telephones (store subscriber profile, passwords, phone books, call history)

69 Laboratory 2 (2/2) What is a card operating system? What is its role? What is the difference between COS and mask? What is the name of the root file? What is the function of the root file? How the rest of the file system is organized? Using the WG10 IEP (electronic purse) example, design a file structure with brief characteristic of the EF for a student Id smart card used for: Identification and access to a building and labs Library access (keeping a record of currently borrowed books) Pre-loaded electronic purse for on-campus canteens, vending machines, copiers What is an access control? Give an example. What is the main difference between COS and open OS? What are the potential problems with open OS for smart cards?

70 Risk Management Security is global Security does not last Security is not free Security requirements depends on applications Pay TV Credit & Debit Pre-Paid Telephone Cellular Phone GSM/PCS Network Security Loyalty

71 Weak software implementation Should be prevented by programming rules! PIN CODE EXAMPLE: PIN CODE RATIFICATION BACKUP & DECREMENT RATIFICATION COUNTER PIN CODE CORRECT? NO DECREMENT RATIFICATION COUNTER YES