May 23th, 2016

Daniela TerraccianoAmedeo VenerosoSoftware Design CentreSTMicroelectronics - Incard Divisiondaniela.terracciano@st.comamedeo.veneroso@st.com

Smart Card Technology

STMicroelectronics 2

• Approximately 43,200 employees worldwide

• Approximately 8,300 people working in R&D

• 11 manufacturing sites

• Over 75 sales & marketing offices

• A global semiconductor leader

• 2015 revenues of $6.90B

• Listed: New York, Paris and Milan

Front-End

Back-End

Research & Development

Main Sales & Marketing

As of December 31, 2015

Application Strategic Focus 3

Safer

Greener

More connected

The leading provider of products and solutionsfor Smart Driving and the Internet of Things

Addressing a Serviceable Available Market (SAM) of around $150B

SmartIndustry

SmartCity

SmartThings

SmartHome

Manufacturing Plant – Italy

150 Million/year chip cardsas installed capacity

C E R T I F I C AT I O N S M 2 M

Marcianise - Italy

From sand to customer 5

Chip design & production

Wafer cuttingWire bonding

Incard R&D software

development

PrintingLamination

Cutting

Card AssemblyPhysical &

Electrical test

Electrical &Graphical

Personalization

WrappingPackagingShipment

leading silicon manufacturer and smart card provider

Highest Security Level reached using Embedded Security

Secure Microcontrollers and Smart Card technologies (Secure Sw + Secure Personalization) provide Reliable, Cost Effective and Scalable Solutions to assure Information Security to any Smart Object

DFN8

6

Introduction to the Smart Card

What is cryptography“hidden writing”

Basic concept: usage of a computational robust algorithm to defend a specific information by using a key

Clear dataSymmetric(DES, AES)

Asymmetric(RSA, ECC)

Enciphered data

Clear data

Clear dataEnciphered

dataClear data

key A key A

key A key B

Availability, Confidentiality, Integrity, Non-repudation

• Contacts and pin-out

Introduction to the smart card system9

• Standard defined in 1987 (ISO 7816)• (not successful) Evolution in 2008 (USB – ETSI TS 102 600)• …today discussions to evolve to more open standards

The Concept of APDU

• All communications with smart cards are based on APDUs

• Communications are Master / Slave (handset -> card)

• APDUs are simple commands with a fixed structure and

optional fields

INSCLA P1 P2 Lc Data In

Data Out

• Depending on the underlying I/O protocol, the complete

sending/receiving of an APDU may require several I/O

exchanges.

Le SW

Simple APDUs

• Initially Smart cards supported such simple commands

• Today things are more complex, despite old services are still required to

be supported

A0 A4 00 00

A0 B0 00 00

A0 D6 00 00

A0 20 00 00

02 2F 00 90 00

02 11 22 90 00

SELECT

READ BINARY

02 11 22 90 00 UPDATE BINARY

0811 22

33 44…90 00 VERIFY

Standardization and interoperability• Smart cards are usually components of bigger

systems

• Banking

• Telecom

• eGovernment etc.

• To guarantee interoperability of components,

standardization is a key driver

Introduction to the smart card system13

• Security features• Active shield• Memory protection unit (MPU)• Monitoring of environmental

parameters• Protection against faults• ISO 3309 CRC calculation block• True random number generator• Unique serial number on each die• Hardware security-enhanced DES

accelerator• NESCRYPT coprocessor for public

key cryptography algorithm (RSA, ECC, ...)

• Code/data signature• ….

• The ST33G1M2

• Cryptographic features

Introduction to the smart card system14

• HW Support• Co-Processor or at least an Hw accelerator for a few features like DES

• SW Support• Provided by means of a Sw Crypto Library certified by the IC supplier itself

•Typical Supported Features• DES• AES• RSA up to 4096 bit• ECC up to 521 bit• Several CRC mode• True RND Generator

High end smartcards typically implement state of the art security procedures (Diffie Helmann, PKCS based encryption, etc.)

• Overview of a telecom product

OS architecture15

Kernel

Chip

JavaCard

UICC USIM ISIM

GP

SSDISD

FS Auth

Toolkit

STK app

HTTPs

ServletRFM RAM

ISD-R

OTA

• Kernel

• Virtualize all the chip resources (HAL)• I/O peripherals• Timers and watchdog• Flash/EEPROM routines• PowerOn procedure• Interrupt management• Clock and power consumption settings• Co-processor management

• Dynamic Memory Management support

• Card Life Cycle Management (including Production

Phase)

• Concurrency Processes Management

OS architecture16

• Java Card

• Subset of Java language

• Applet selection

• Multi-channel

• Applet bytecode execution (JVM)

• JC API

• JDK

• JCCK

• Further details later…

OS architecture17

• Global Platform

OS architecture18

GP is born to solve typical issues of multi-application cards:

� Proliferation of non compatible, proprietary cards, devices, and system platforms.

� Difficulty in dynamically updating applications and services in a secure manner which increases cost.

� Extended time to market due to integration issues.

� GP is the de-facto standard interface for card administration

OS architecture19

• OPEN: The GP-defined runtime environment:

• supersedes the JCRE

• enforces card administration rules

• offers service API to applications

• handles the registry of on-card packages and applications

• Issuer Security Domain (ISD): On-card representative of Card Issuer

• Supplementary Security Domains (SDs): On-card representative of 3rd party application providers

• Global Platform

• Telecom Applications (SIM/UICC/USIM/C-SIM)

• Network Authentication procedure

• File System

• Security (PIN, Unblock,…)

• Support of several acces technology(2G, 3G, 4G)

OS architecture20

• SIM Toolkit• Framework to allow STK (SIM Toolkit) applets access to the

mobile handset resources, so to provide the user with the SIM menu and implement the MNO (Mobile Network Operator) services• Display• Network services (SMS, Voice Calls, Data Exchange,…)• Ear speakers• Mobile keyboard

• Can control the calls and the SMS originated by the ME

• Allow to the STK applets accessing the SIM File System

• Manage the STK applet security, registration, life-cycle and triggering

OS architecture21

• Over The Air• Secure protocol to perform remote applet and file

management on card without interaction and notification to the user

• Tool in the MNO hands to change the SIM content and so implementing new services by means of the couple applets and OTA server

• Counterpart is the OTA server owned by the MNOs

• MNO can perform administration service on card

OS architecture22

Over the air stack

HTTP

TLS

TCP/IP BIP

APDUs

TLS

HTTP

CommandsCommands

Multi subscription SIM

• A new concept for SIM card• For M2M and consumer market needs• Requirements:

• Provide multi telecom subscription on the SIM• Load / Enable / Disable / Delete subscriptions on the field• Clear separation of roles between actors

Telecom operator #1

Telecom operator #2

Telecom operator #3

Remote control credentials

SIM OS

User selects

Remote selectRemote Load / delete

IoT: the large field of opportunities 25

eMobility

Smart Home

Smart Me

Remote Monitoring

All Smart Systems in Personal Networks, Smart Grid, Smart Cities, Smart Me, converging

through “Internet Of Things”

Smart Street Lighting

Power Plant

Renewable Energy

Factory automation

Plug-in Hybrid Electric Vehicle

Home and Building Automation

Smart Metering

AMI/AMR

26Internet of Things - Model

Source: GSMA CLP.13 – Sec. Guidelines Endpoint Ecosystem

Implementing an OS

• Multiple interfaces • A multi task operating system

• Small RAM (<30 kb) • Non preemptive schedulers

• High reliability • Maximum stack occupation

• Security requirements • Redundant code

• NVM granularity • Anti-tear mechanisms

Our principles….

May 23th, 2016

Daniela TerraccianoJava Card & GlobalPlatform DevelopmentSoftware Design CentreSTMicroelectronics - Incard Divisiondaniela.terracciano@st.com

Security and Java Card

• The main value offered by the smart card is security, it shall be

able to protect the keys, passwords, user data against the several

type of known attacks

• Attacks evolve continuously and the card security evolves

accordingly

• Countermeasures shall be developed against several type of

attacks and shall guarantee adequate performances

• This know-how is the most important competitive advantage

because a lot of patents have been filed for that

• To prove card security, smartcards are certified by third party

independent laboratories performing code reviews and physical

attacks

Security features and certifications29

A certification scheme: Common Criteria - ISO 1540830

• International agreement on the secure development methods and 7 discrete effort levels

• Basis for evaluation of security features of IT products and systems, allowing comparisons between the results of independent security evaluations

• Assists in specification, design and implementation of IT products or systems

Evaluation Assurance Level (EAL)

EAL7EAL6EAL5EAL4EAL3EAL2EAL1

• Formally Verified design and Tested• Semiformally Verified design and Tested• Semiformally Designed and Tested• Methodically Developed, Tested and Reviewed• Methodically Tested and Checked• Structurally Tested• Functionally Tested

Smart card products

Security Evaluation of Smart Card Products31

Smart card products are typically evaluated EAL4+ or EAL5+.

Vulnerability analysis is performed according to well known rules and patterns

identified by security experts (Joint Interpretation Library - JIL)

Physical Attacks• Overcoming sensors and filters• Perturbation Attacks (fault / double-fault injection)• Attacks on RNG

Non-invasive attacks to retrieve sensitive data (keys / PINs)• SPA/DPA, H.O. DPA, EMA• Differential Fault Analysis (DFA)

Software attacks• Exploitation of Test features• Downloading of Ill-formed Java Card applications• Buffer overflow or stack overflow• Protocol based / man-in-the-middle attacks

• Security features and certifications

• The source code has to use in the correct way all the security

features offered by the smart card chip:• Jittered clock• Active shield • Memory protection unit (MPU) • Monitoring of environmental parameters • Protection against faults • ISO 3309 CRC calculation block • True random number generator • Unique serial number on each die • Hardware security-enhanced DES accelerator • Coprocessor for public key cryptography algorithm• Many others (not possible to be disclosed)

Main problems requiring a dedicated solution32

• Security features and certifications

Main problems requiring a dedicated solution33

Example: password verification can be sensible to the timing attackWrong implementation:

if ( strcmp( givenPasswd, storedPasswd ) != 0 ) return -1;Good implementation:

char* c1 = givenPasswd;char* c2 = storedPasswd;char error = 0;for (; *c1 != 0 && *c2 != 0; c1++, c2++ ) // loop

error |= *c1 ^ *c2; // collect diff in errorif (error | *c1 | *c2) // fail if any not zero

return -1;return 0;

An example of OS component: Java Card34

• Java Card brings into the smart card technology the advantages of the Java “ecosystem”:

• Strong typing• Object Oriented paradigm• Cross-platform Interpreted language (Virtual Machine-based)• Automatic run-time management of memory resources • Reduction of typical programming errors and pitfalls of native languages

• Application framework explicitly designed for smart cards and multi-application scenarios

• Rules for secure installation and removal of applications

• Built-in cryptographic framework supporting DES, AES, RSA,ECC

• Byte-code verification (off-card tool)

Java Card architecture35

A smart card platform able to execute “Java” applications (Applets )

• Java Card bytecode interpreter (Java Card Virtual Machine) only supports a subset of Java bytecodes and Java features.

• Runtime environment (JCRE) handling:• APDU Command dispatching• Application installation / deletion• Allocation / de-allocation of memory resources• Application isolation• Persistence and Atomicity

• Application framework (Java Card API):• Applet life cycle• I/O• Cryptography

Native methodsJCVM

Industry-Specific Extensions

JCRE

AppletApplet Applet

Industry-Specific ExtensionsIndustry-Specific Extensions

JC API

Application support36

• Application installation and registration with a unique identifier (AID)

• Application selection and command dispatching:

JCRE

AppletApplet Applet

JC API

APDUs

• All the incoming APDUs are always sent to the JCRE

� Applet class entry point methods:� install()� select()� process( APDU apdu )� deselect()

� If APDU is a SELECT (by AID):� JCRE processes the

SELECT� JCRE selects the applet

� Any APDU (including SELECT) is forwarded to selected applet to be processed

Java Card key concepts37

• Like for Java, executable code is logically grouped into ‘packages’:

• Library packages (e.g. JC API, libraries, etc..)• Packages containing application code (applet packages)

• Application execution model is defined by the Java Card framework � each application shall extend the ‘Applet’ base class defined in the JC framework API

• Split VM : Due to smart card limited resources and computation capabilities, Java .class files cannot be executed on a Java Card: all the .class of a package are grouped and transformed in a single compact file: the CAP File.

JC memory models and object life-cycles38

• Objects and Arrays created with the “new” keyword are always instantiated in Non-volatile-memory (NVM):

• Objects/Arrays and their content (i.e. values in fields) will persistacross power-off

• Each field/element update will require EEPROM/FLASH writing• Updates of fields/elements will be atomic• Additional APIs allows to group updates in “transactions”

• Arrays can be also created with JC specific APIs (JCSystem.makeTransientXXXArray()):

• Elements will be allocated in RAM• Value of array elements will be cleared at reset/deselect of

application• Array object header will be always stored in persistent memory

• The array will in any case “survive” to reset

Object Deletion / Garbage Collection39

• With respect to Java, JC only provides optional limited garbage collection functionalities:

• The functionality is “on-demand”• JCSystem.requestObjectDeletion() shall be explicitly

called• The memory space is reclaimed at next APDU

• JC Garbage Collection is only suitable for:• Resizing objects• Atomically update large objects:

• Create a new, larger object• Update reference to the object• Remove old object (by issuing a garbage collection request)

Cryptographic framework40

• JC API framework provides to the applet state-of-the-art cryptographic services:

• Secure Random, CRC• DES, AES, EMV 2000,, Elliptic Curve, RSA 2.0• MD5, SHA-1, SHA256, etc..

• Crypto functionalities are abstracted by simple objects defined in the JC API framework

• JC Platform implementers shall provide an implementation of the algorithms which is compliant with application security requirements

• JC applet developer shall simply require to the JC platform a new instance of the required algorithm and use it!

Multi-application support 41

� Sharing data across firewall:� Not allowed by default� Applet shall explicitly define

the interface for sharing its data

� Applets shall invoke a special JC runtime service to get the “shareable” interface.

• Applet isolation: the Firewall• A separate context is automatically assigned to each package

containing applets• Access to fields, objects and methods across firewall is forbidden.

Thanks!Daniela Terracciano

Amedeo VenerosoSoftware Design Centre

STMicroelectronics - Incard Divisiondaniela.terracciano@st.comamedeo.veneroso@st.com