Jean-Jacques Vandewalle Systems Research Labs

04/19/23

Smart card research: beyond OS and securityan industrial perspective with a software point of

view

Jean-Jacques VandewalleSystems Research Labs

2 Smart card research: beyond OS and security

Goals of this talk

•To understand current smart card research context

•To motivate and highlight research perspectives that come from the evolution of smart card platforms

•To arouse discussions, project ideas, new applications of results, etc.


First view on smart cards

• Most smart/secure/cheap/convenient...embedded devices• Most constrained/particular/difficult to...embedded devices

• Embed fixed native functions or is an open platform (Java, .NET) enabling post-issuance of applications

• Realize complex operations (security-related, VM) with limited processor, few energy, and small memories

• Are produced by specialists because of specific chip features, addressable but slow NVM, soft and hard counter-measures to attacks, and conformance to legacy standards (ISO 7816)

• Though mass-produced, have a complex lifecycle from mask burning up to one-per-one personalization

• Interact with external devices through specific protocols


Current researchRicher OS capabilities

• Multithreading• Automatic garbage collection • Real time• Power management

Powerful open platforms

• High level language with complex runtime (JVM, .Net)• Standard communication stack (TCP/IP)

Validation and verification

•Test generation using models• Provable properties (security model, applet correctness)

Secure platform

• Code verifications (type safety)• Access control (information flow)• Resources usage guarantees (memory, CPU)


BankingE-Government

Mass Transit

Mobile Telecommunications

PublicTelephony

W-LAN

Access controlDigital RightsManagement

EnterpriseSecurity

Retail

Current usage


•Current research targets an open platform highly secure embedding rich OS features directly connectable to WAN

•Current usage is still limited to user authentication and cryptographic

functions fixed functionality with few dynamic evolution behind-the-scene network usage

A paradoxical situation?

…Research is in advance, or complementary research is

needed?


Second view on smart cards

•Secure open smart card platforms enable the usage of smart cards as portable (mobile) personal service platforms

•In such a perspective two issues and needs appear

What should be the platform framework?• A framework to deliver services over WAN to card devices

and to administer smart card platform and services

How card services should be deployed?• An integration architecture to deploy smart card services

within services infrastructure


Framework requirements•To allow services to be remotely delivered and administered onto (possible multi-operated) open smart cards

•To allow multiple services to cooperatively share a common framework and execution environment

•To be an OS-neutral way of delivering and administering services

•To be agnostic about the model of the application implemented by a service (server,

client, daemon, agent, etc.) the policies implied in services management: for instance, the

life-cycle policy or the security policy


Framework illustrated

Application services Shar

ed Service

Appli. Fw Appli. Fw. Appli. Fw. Services operated by the platform

Platform FrameworkPlatform manager

Framework

OS

Hardware platform Communication means

Platform


Framework research•Current smart card framework (JC 2.2, GP, STK) are limited to current OS capabilities and defines one way to deliver and administer card services

•Industry-standard framework such as OSGi (for home or vehicle gateways) targets larger platforms and does not deal with smart card specificity complex platform life-cycle persitent memory model

•Future open platforms will clearly need a framework, basic services and a platform manager that takes benefits from improved card OS features to support both card specificity and an unlimited variety of services


Integration architecture (1)

•Smart card services are useless if they don’t participate in distributed transactions with other services in their environment

Client applications

Card service

BackendServer

Infrastructure


Integration architecture (2)

•So far, card services have been deployed in controlled environment (telecom operator, bank, or government network) limiting the interest of card services within the managed environment

•Open services infrastructure tends to federate multiple services by supporting the discovery of, the connection to and the communication with services from client applications

•Open smart cards can leverage such infrastructure to deploy their services thanks to an integration architecture


Integration illustrated with Web

Intranet

Smart Card

Card Service

Card Framework

Card Intermediary

Agent

Applet Proxy+ Servlet

DeployGet /Post

MessagesServiceObject

EnterpriseApplication

Server

ServiceDescriptions

Service

Descriptions

Service

Agents

Back-end Server

ServiceAgent

ServiceAgents

ServletBundle

Messages

Appli.Applicationor Web Browser

Client Machine

CMS


Integration illustrated with Jini

Jini

Appli.Applicationor Jini Finder

Client Machine Smart Card

Card Service

Card Framework

Card Intermediary

Agent

Service Proxy + Service Object

JoinLookup

MessagesMessagesServiceObject

LookupService

ServiceDescriptions

Service

Descriptions

Service

Agents

CMS

Back-end Server

ServiceAgent

AppletAgents

ServiceObject


Integration research

•Previous illustrations are just example of deployment schemes for dynamic announcement of legacy smart card services

Simpler schemes might be investigated with card services globally reachable or directly accessible without intermediary

More complex schemes might be investigated taking into account federation of multiple services transactional context, security requirements, etc…


Third view on smart cards•Smart cards are either

Open platform Native platform secure post-issuance confined pre-issuance generic card OS all-in-one OS and applis application server-like romized applications portability and interop. ad-hoc specifications rapid development long development cycle

•The two alternatives are costly Open cards requires big chip and complex OS Native cards require to redevelop the OS

along with applications

•Native cards are still necessary to provide the “right platform at the right price” to customers saying: “I don’t need an open platform with post-issuance, GC, rich APIs etc. I don’t want to pay the price for those things!”


Open platform adaptation•The idea consists in leveraging on the full-fledged open platform to produce “custom” smart card editions thanks to an automated process

•Platform adaptation requirements A careful platform design with adaptation in mind

• Uniformity at the basics, (un)pluggable components, generative programming, A/S-OP for platform code,…

Instrumentation techniques to produce a custom edition with the only required system data and code for running the targeted applications

• Code specialization, romization, memory initialization, conditional compilation,…

Relevant data analysis to feed the automated adaptation process with right inputs


Platform adaptation illustrated

Serialize application fw libraries & application codesTweak the platform components

ROMize all the codes and dataApply drastic static optimizations

Classes

Repository

Loader

Converter

Linker

Code

Optimizer

Execution

Engine

(De-)Serializer

ROMizer

Memory management Hardware Support

Core & System ClassesShell

Scheduler

Communication

Stack

Debugger

Standalone Application

Model 1 Model 2 Model 3

Application DevelopmentDeveloper edition

Win/Linux platform(s)• Develop, debug, optimize, and test applications• Experiment different application framework• Benefits from full-fledged platform

Appli. Mgt

Classes

Repository

Loader

Converter

Linker

Code

Optimizer

Execution

Engine

Serializer

ROMizer

Memory management Hardware Suppott


Scheduler

Communication

Stack

Pre-issued Application Classes

Pilot/Real DeploymentPost-issuance edition

high-end cards• Deploy, connect, comm-unicate with applications• Keep the full-fledged platform framework• Allow patches and removal/additions of codes

Appli. Mgt

Classes

Repository

Loader

Converter

Linker

Code

Optimizer

Execution

Engine

Serializer

ROMizer

Memory management Hardware Support


Scheduler

Communication

Stack

Application Classes

Real DeploymentMinimal edition low-end cards

• Produce, initialize, personalize card & applications • Keep only the platform manager part that allow to monitor the card (e.g.)

Appli. Mgt


What we have seen

•Current smart card research focuses on Rich operating system features in small devices High level of confidence on the card platform thanks

to security, validation, and verification techniques

•To provide their full potential (and meet business applications?), such secure open card platforms might be complemented by research initiatives targeting A platform framework to operate multiple services Integration architectures to deploy card services in services

infrastructure Adaptation techniques for producing an optimized

application-specific system from an open system


Final view on smart cards • The position of future open smart cards is between

High-end electronic consumer products embedding• An operating system kernel (Symbian, Embedded

Linux, .Net kernel, etc.) Generally proprietary and sometimes real-time

• A well-defined and runtime edition (J2ME CLDC/CDC, .Net compact) on top of an underlying operating system

Generally over-sized and difficult to optimize With network connectivity capabilities

• Some dedicated profiles (APIs and application models)

Targeting dedicated markets (mobile phone, terminals, etc.)

Low-end embedded consumer products with• No general-purpose operating system• Closed framework and poor (no) connectivity• Ad hoc hand-written functionality


Platform outcomes

•A deployed platform for open and connected “in-the-middle” embedded devices E.g., next-generation smart cards, smart toys,

automotive, operated appliances, ... Benefits: rich and secure OS for small device with an

open platform framework and integration architecture

•A production platform to produce dedicated “Software System on Chip” With all-in-one OS and applications code produced from

the full-fledged platform, then optimized and adapted from applications requirements and to chip characteristics

E.g., native smart cards, traditional appliances, ... Benefits: huge market, alternative to hand-written code


Conclusion•Smart card researches are at the forefront of research to design computing platforms in very small devices

•Ambiant computing relies on a connected network of small computing devices providing services that are federated to work together for a given purpose

•Smart cards can be an interesting research test bed to work on some of the required technologies for ambiant computing Secure powerful open platform,

generated application-specific platforms Framework for operated devices Integration architecture in services infrastructures

Personalcomputing

M2M H2Minterfaces

Embedded

systems

network

04/19/23

Thank you!Any question?

www.gemplus.com

[email protected]

Documents

Jean-Jacques Vandewalle Systems Research Labs