A UNIX Filesystem for Smartcards

CITI Technical Rep ort 98-8

SCFS: A UNIX Filesystem for Smartcards

Naomaru Itoi

[email protected]

Peter Honeyman

[email protected]

Jim Rees

[email protected]

Abstract

Smartcard software develop ers su er from the lack of a standard

communication framework b etweenaworkstation and a smartcard. To

address this problem, we extended the UNIX lesystem to provide ac-

cess to smartcard storage, which enables us to use les in a smartcard

as though normal UNIX les.

Decemb er 3, 1998

Center for Information Technology Integration

University of Michigan

519 West William Street Ann Arb or, MI 48103-4943

2 itoi

1 Intro duction On-chip software standards: JavaCard [14]

and MULTOS [15].

Today, it is easy to purchase smartcards in rea-

Although these standards provide abstrac-

sonable prices, e.g., $5 - $20 for each. How-

tions at a higher level than ISO-7816-4, it re-

ever, smartcard software development is hard:

mains a challenging task for develop ers to se-

smartcard software develop ers have long suf-

lect a standard, purchase all software and hard-

fered from the lack of a user friendly stan-

ware required, learn API and to ols, and nally

dard communication proto col b etween appli-

implement software. Furthermore, those stan-

cation software and a smartcard. The ISO-

dards do not eliminate problems with interop-

7816 communication proto col [9] is so widely

erability{ e.g., OCF limits the programming

accepted that virtually all smartcards supp ort

language to Java; PC/SC is used only with

it. However, the proto col is not a particularly

Windows { and create their own API dep en-

desirable one:

dencies, b ecause software written for one stan-

It is a primitive message passing proto-

dard do es not run with another. We discuss

col. Providing only read and write op-

these issues in Section 5.1.

erations for raw data, it do es not de ne

Our solution to this problem is to embrace a

higher interfaces such as UNIX les and

classic, sophisticated API { the UNIX lesys-

I/O streams. This hamp ers our abilityto

tem { instead of inventing a new one. The

build application software.

UNIX lesystem API suits a smartcard well

b ecause a smartcard is a passive device used

Although all smartcards supp ort ISO-

for secure storage: a smartcard stores data se-

7816, details of implementation of the pro-

crets, and resp onds to requests from a work-

to col di ers among vendors and typ es of

station to read or write the data. It do es not

smartcards. This requires software devel-

initiate actions. This passivityischaracteristic

op er to tailor their applications to sp eci c

of storage devices such as hard disks.

smartcards.

In UNIX op erating systems that supp ort

Di erences among smartcards range from

vnodes equivalently, Virtual Filesystem, or

trivial ones, such as di erent op co des, to

VFS [11] [13], it is p ossible to write a virtual

essential ones, such as di erent authen-

lesystem that communicates with a sp ecial

tication mechanisms, etc. For example,

hardware device, e.g., a smartcard, and mount

the CLA byte of application class is 0x00

it in the UNIX lesystem name space. The

in some smartcards Giesecke & Devrient

mounted hardware device then b ecomes iden-

STARCOS Version 2.1, while it is 0xc0 in

tical to any UNIX lesystem hierarchy from

others Schlumb erger MultiFlex.

the p ersp ective of a user or application soft-

ware. For example, if a smartcard is mounted

To address the de ciencies of ISO-7816,

on /smartcard, it is p ossible to use UNIX com-

many new standards have b een prop osed. Ex-

mands suchasls, cd, pwd, and cat, and system

amples are:

calls suchasopen, read, and write on les in

General purp ose standards: Op en Card

the smartcard.

Framework OCF [2, 8] and PC/SC [3,4].

Wehave implemented a smartcard lesystem

or SCFS in the Op enBSD-2.2 kernel. With

Sp ecial purp ose standards: PKCS 11

SCFS mounted, a user or an application can

[12] for cryptography, EMV [5] and SET

use les in a smartcard as she would normal

for electronic commerce.

UNIX les.

\Application software" is a program running on a

The remainder of this pap er is organized as

workstation that communicates with a smartcard. A

follows. Section 2 describ es our goals and the

program running on a smartcard is called \on-chip soft-

design of SCFS. Section 3 details implementa-

ware".

tion of SCFS. Readers not interested in im-

Almost all smartcards supp ort ISO-7816-1, 2, and

3. Many supp ort ISO-7816-4 [17]

4 3

Op enBSD is a free, 4.4BSD-based op erating sys- For description of \CLA" and \application class",

tem. http://www.openbsd.org please see Guthery and Jurgensen [6] or ISO-7816 [9]

Smartcard Filesystem 3

plementation details maywant to skip Section UNIX lesystem. For example, without direc-

3. Performance evaluation in Section 4 shows tory entries, it is imp ossible to implement ls

that the overhead of SCFS is small and do es prop erly.

not substantially degrade the p erformance of Wehavetwochoices, with concomitant

smartcard software. We discuss SCFS with a tradeo s:

comparison to other standards in Section 5 .

Dictate an internal format on a smartcard

Future direction is in Section 6 and concluding

to store information such as directory en-

remarks are in Section 7.

tries, length of a le, etc., in a le in a

smartcard. This provides full functional-

ity of UNIX lesystems.

2 Design

Degrade functionality of SCFS. For exam-

ple, no ls,nocat.

2.1 Design Goals

We compromise b etween the twochoices. We

Our goal is to provide a user friendly interface

b elieve it is essential to b e able to determine a

to access a smartcard. We de ne design goals

smartcard's directory structure through UNIX

as follows, although not all can b e achieved, for

commands suchasls, so SCFS requires di-

reasons outlined in Section 2.2:

rectory structure information to b e stored in

a smartcard. We also require a smartcard

Files in a smartcard should b e indistin-

guishable from other UNIX les. to store le lengths b ecause they are neces-

sary to implement the read and write system

A smartcard can b e accessed with any

calls. Every directory or DF in ISO-7816 in

UNIX system calls e.g., creat, open,

a smartcard has a le called ff.fe containing

read, and write.

the requisite metadata.

UNIX commands e.g., ls, cd, pwd, and

2.3 Design

cat can b e used to access les in a smart-

card.

Inspired by Arla [18], SCFS is implemented as a

kernel mo dule, xfs, that handles VFS requests,

The smartcard VFS must b e able to access

and a user daemon, scfsd, that communicates

any smartcard that supp orts ISO-7816.

with an ISO-7816 smartcard. Figure 1 shows

the overview of the design.

The smartcard VFS should hide details

ab out a smartcard to users. ISO-7816 interface Smartcard

Application SCFSD

Security of a smartcard must b e preserved. UNIX

Filesystem

No smartcard les may b e cached in the

interface User-level UNIX system b ecause a smartcard is a

more secure place to store data see the Kernel

end of Section 2.3. VFS XFS

Figure 1: SCFS design

2.2 Design Problems

Ahuge obstacle to achieving our goals is the

absence of a standard way to request metadata

When an application calls a VFS op eration

information ab out les in a smartcard. Some

e.g., read,orwrite to a smartcard le, the

information essential for the UNIX lesystem

kernel mo dule up calls scfsd to request service.

is simply not present in a smartcard, e.g.,

sends them to Scfsd creates ISO-7816 APDUs,

le sizes, directory contents, and time stamps.

An Application Protocol Data Unit, or APDU, can

Without such information, it is imp ossible to

b e viewed as a framing proto col for messages passed

implement the complete functionality of the from application software to a smartcard.[9].

4 itoi

a smartcard, gets returned data, and passes it 3.2 Kernel Mo dule xfs

to the kernel mo dule.

The kernel mo dule xfs implements a virtual

Separation b etween xfs and scfsd allows us

lesystem, the pioctl system call, and com-

to use an existing ISO-7816 library [16] for han-

munication with scfsd.

dling the ISO-7816 proto col and dealing with

The virtual lesystem consists of several

its complex timing requirements. Kernel co de

functions called by the kernel when a le in

is minimized, making SCFS easy to debug and

SCFS is accessed. For example, the core part

p ort.

of the read system call is implemented by the

To absorb di erences among smartcards,

xfs read vno de op eration in the xfs.

SCFS requires some knowledge of a smart-

We describ e some imp ortant vfs op erations,

card b efore it is mounted, e.g., existence

xfs mount and xfs root, and some im-

of sp ecial APDUs, op co des used for AP-

lookup, p ortant vno de op erations, i.e., xfs

DUs, ATRs they return, etc. The informa-

xfs read, xfs write, xfs getattr and

tion is stored in a SCFS con guration le,

xfs readdir in Section 3.5.

/usr/scfs/etc/scfs.scdb by default.

Xfs is typically loaded into the kernel at b o ot

SCFS automatically identi es a smartcard

time. When xfs needs to communicate with a

typ e from its ATR. When a reset signal is

smartcard, it p erforms the communication by

sent to a smartcard, it resp onds with a 4 -

up calling scfsd.For example, xfs read in-

32 byte ATR, unique to each smartcard typ e.

vokes xfs message readsc in scfsd. Xfs

The SCFS con guration le has a database of

waits until it receives data from scfsd, and

known ATRs. If the ATR from the smartcard

sends the data back to the application with the

is listed in the con guration le, SCFS retrieves

uiomove kernel function.

the entry for that typ e of smartcard. Details

ab out the con guration le are describ ed in

3.3 SCFS daemon scfsd

Section 3.6.

Unlike most UNIX lesystems, SCFS do es

Scfsd p erforms op erations requested by xfs.

not cache data read or written b ecause caching

For requests that require smartcard access,

might degrade the security of data residentina

scfsd translates the request to ISO-7816 AP-

smartcard. Data in the UNIX lesystem typ-

DUs. Figure 2 shows an example of message

ically a hard disk is not protected as securely

ow when an application requests to read 8

as in a smartcard. For example, a UNIX user

data bytes from a smartcard.

with administrative or \root" privileges can

{00, a4, b0, 00, 08} access all data in a UNIX lesystem, while she y not b e able to access les in a smartcard ma Smartcard

Application SCFSD eys. protected with PINs or k data read(8 bytes) data msg_readsc

msg_installdata(data)

3 Implementation

VFS XFS

3.1 Overview

data

As describ ed in Section2.3, SCFS is separated

intoakernel mo dule xfs and a SCFS dae- Figure 2: Reading 8 data bytes from a

smartcard

mon scfsd, detailed in Sections 3.2 and 3.3,

resp ectively. Communication b etween xfs and

scfsd is detailed in Section 3.4. Implementa-

tion of SCFS is based on Arla-0.6. Communica-

tion b etween xfs and scfsd is derived directly

3.4 Communication b etween xfs

from Arla.

and scfsd

Xfs communicates with scfsd through RPC. Answer To Reset.

Smartcard Filesystem 5

When xfs needs access to a smartcard, it con- Vno de op erations:

structs a request message, puts it into a mes-

lookup xfs

sage queue, and waits for scfsd to reply.Code

for sending a request to read 8 bytes from a

lookup translates a path to an 8 Xfs

smartcard is as follows:

byte fid. It checks if the requested path-

name and its parent are b oth in the direc-

struct xfs_message_readsc msg;

tory structure. If they are, it constructs

and returns the d. Currently, a path

msg.header.opcode = XFS_MSG_READSC;

length is restricted to four comp onents b e-

msg.buf = buf;

cause a fid is 8 bytes long, big enough to

msg.size = 8;

hold four ISO-7816 comp onents, which are

msg.offset = 0;

twobytes each. We map these twobytes

fidcpy msg.fid, xnode->handle;

into their ASCI I equivalents in the natural

xfs_message_rpcfd, &msg.header,

way.

sizeofmsg;

xfs read

After invoking xfs message rpc, xfs

read reads data from a p ossibly Xfs

sleeps until it receives the result of the request.

PIN-protected smartcard le, as follows.

Scfsd eventually receives data from a smart-

1 It selects the target le. 2 When

card and sends it back to the kernel mo dule.

the current le and the target le have the

Here is an example of sending a reply message:

same parent, the target le is selected by

a select APDU. Otherwise, the entire path

struct xfs_message_installdata msg;

from the ro ot must b e navigated; ISO-7816

do es not allow selection of an arbitrary le,

msg.header.opcode = XFS_MSG_INSTALLDATA;

only one in the currently selected direc-

memcpy msg.buf, data;

tory, so in this case, xfs read selects the

msg.size = size;

ro ot le 3f.00, and moves down a path

xfs_send_message_wakeupfd, error, msg;

one by one to the target le. 3 With the

le now selected, xfs read sends a read

APDU e.g., c0 b0 00 00 length to the

smartcard. 4 If the read request fails b e-

3.5 Imp ortant VFS/Vno de op er-

cause the le is protected by a PIN, scfsd

ations

prompts the user for a PIN. The prompt

In this section, we detail the implementation of

is directed to the controlling tty of the ap-

some imp ortant VFS and vno de op erations.

plication that issued the system call. 5

VFS Op erations:

Finally, scfsd passes the data read back

to the user via a call to the xfs layer and

xfs mount

kernel uiomove.

Xfs mount mounts SCFS on a sp eci ed

write xfs

directory. It rst sends a reset signal to the

smartcard. When it receives ATR from the

Xfs write b ehaves identically to

smartcard, it scans the con guration le to

read, except for the direction of xfs

nd a smartcard description that matches

data.

the ATR, reads the con guration informa-

xfs getattr

tion, initializes scfsd, initializes xfs, and

creates the mount p oint.

Xfs getattr installs a VFS attribute

structure struct vattr and an XFS

xfs root

A fid is a le identi er that is unique in SCFS,

root op eration selects a ro ot direc- Xfs

consisting of names of the le itself and its ances-

tory 3f.00 in a smartcard and installs

tors. For example, a fid of a le 3f.00/77.77/77.01 is

an XFS no de and a vnode forarootnode. 77.01.77.77.3f.00.ff.ff.

6 itoi

attribute structure struct xfs attr. ATR 3b321504910{

CARDNAME CyberFlex

Scfsd p erforms the actual construction of

MULTIFLEXPIN no

the XFS attribute structure and sends it

MULTIFLEXGETRES no

to xfs, which converts it into a VFS at-

CLA_DEFAULT c0

tribute structure.

CLA_VERIFYKEY f0

CLA_READBINARY f0

xfs readdir

CLA_UPDATEBINARY f0

readdir is typically called bya Xfs

CLA_READRECORD -1

getdirentries system call, often as a

CLA_UPDATERECORD -1

}

result of an ls command. It returns di-

rectory entries struct dirent of a se-

ATR 3b21450{

lected directory. Eachentry describ es a

CARDNAME MultiFlex

le or a directory in the selected directory.

MULTIFLEXPIN yes

ISO-7816 shortcomings require that we de-

MULTIFLEXGETRES yes

ne our own metadata strategy, describ ed

CLA_DEFAULT c0

in Section 2.2. Xfs readdir constructs

CLA_VERIFYKEY f0

full directory entries from the directory en-

}

tries and from our metadata le and re-

turns them to the application.

ATR 3b230351180{

CARDNAME PayFlex/MCard

pioctl

MULTIFLEXPIN no

MULTIFLEXGETRES no

Some functionalities in a smartcard do not

CLA_DEFAULT 00

t the concept of a lesystem. For exam-

}

ple, there is no system call to read a PIN to

authorize a user. However, these function-

alities are necessary to take advantage of

The byte string after the \ATR" tag is

security features of a smartcard. To incor-

matched with the ATR returned from a smart-

p orate them into SCFS, we implemented

* tags de nes CLA card at reset. The CLA

the pioctl op eration. Like ioctl,

bytes for sp eci c APDUs, used by scfsd to

pioctl takes op co de and data and p er-

construct APDUs. -1 means that the APDU

forms an op co de sp eci c action.

is not supp orted in the smartcard typ e. If

a CLA byte is not sp eci ed for the APDU,

Implementation of pioctl is straight-

CLA DEFAULT is used. For example, in Cy-

forward, translating one op co de to one

b erFlex, the CLA byte is 0xf0 for the ver-

APDU. Pioctl implements verify PIN,

key, read binary, and up date binary AP- ify

verify a key,internal authentication, exter-

DUs. Read record and up date record APDUs

nal authentication, get resp onse, and get

are not de ned. 0xc0 is used for the CLA byte

challenge APDUs.

for the other APDUs.

3.6 Con guration File

4 Performance Evaluation

The con guration le stored in

/usr/scfs/lib/scfs.scdb by default

Here weevaluate the p erformance of SCFS.

includes entries for ATR, the name of the

smartcard, the CLA byte used for APDUs,

whether the APDUs are supp orted by the

4.1 Metho d

smartcard, the typ e of supp orted PIN protec-

For four di erent settings of read and write

tion, etc. An example of a con guration le is

as follows:

system calls, we measured total elapsed time

and time sp ent to access a smartcard. The dif-

Pioctl originated in AFS. We use pioctl to

ference re ects lesystem overhead. Figure 3

avoid adding a new system call; this decision will b e

shows this relation. revisited someday.

Smartcard Filesystem 7

0.6 End 32.6 Send read receiving read(2) start reading end reading read(2) APDU to card data call smartcard smartcard returns Start Start Complete read receiving read data Total Time 0 11.9 33.0 (ms)

smartcard access time

Figure 4: Breakdown of 8 byte read

scfs overhead scfs overhead

Figure 3: Performance Evaluation

dards.

The four settings are read 8/128 bytes

OCF

and write 8/128 bytes. The measurement

Op enCard Framework is middleware that sup-

is p erformed for a Schlumb erger MultiFlex

p orts a smartcard with Java[2,8]by provid-

smartcard, communicating at 9.6 Kbps with

ing high-level APIs, vendor transparency, card

Op enBSD-2.2 op erating system on Pentium-

typ e transparency, and extensibility. These ob-

133MHz.

jectives are similar to ours. The principal ad-

vantage of OCF is that it employs Java. Pro-

4.2 Result

grammers familiar with Java can start smart-

card programming easily. The following is an

The result is shown in Table 1. Command

example taken from \Op enCard Framework 1.1

names, total time, time sp ent for smartcard

Programmer's Guide" [7]. It reads a le \id"

communication, and SCFS overhead are shown.

0xc009 and prints it out to standard output.

All times are in ms.

public static void mainString[] args

Command Total SC Overhead

{

Read 8 bytes 28.9 28.2 0.7 2.4

System.out.println

Read 128 bytes 190.2 189.4 0.8 0.4

"reading smartcard file...";

Write 8 bytes 63.4 62.7 0.7 1.1

Write 128 bytes 1259.5 1258.9 0.7 0.1

try {

SmartCard.start;

Table 1: Performance Evaluation Result

// wait for a smartcard with file

The numb ers show that SCFS overhead is

// access support

negligible. Most of the time is sp ent communi-

CardRequest cr =

cating with the card.

new CardRequest

FileAccessCardService.class;

SmartCard sc =

4.3 Breakdown

SmartCard.waitForCardcr;

Figure 4 shows a breakdown of the 8 byte read.

It takes 11 ms to send the read APDU, 11 ms

FileAccessCardService facs =

for the smartcard to pro cess a read command,

FileAccessCardService

9 ms to receive data from the smartcard, and

sc.getCardService

1 ms SCFS overhead.

FileAccessCardService.class, true;

CardFile root = new CardFilefacs;

CardFile file =

5 Discussion

new CardFileroot, ":6964";

5.1 Related Work

byte[] data =

facs.readfile.getPath, 0, Here we discuss three imp ortant related works,

file.getLength ; OCF, PC/SC, and some sp ecial purp ose stan-

8 itoi

tives are similar to OCF and SCFS. According sc.close;

to part 6 of the sp eci cation [4], the PC/SC

API is similar to the UNIX lesystem, featur- String entry = new Stringdata;

ing Op en, Close, Read, Write, Seek, entry = entry.trim;

etc. Therefore, usability of PC/SC and SCFS System.out.printlnentry;

are similar.

} catch Exception e {

Unlike OCF, PC/SC supp orts multiple lan-

e.printStackTraceSystem.err;

guages and developmentenvironments, such

as C, VC++, VB++, and Java. However,

} finally { // even in case of an error

it is used only with Windows op erating sys-

try {

tems. While SCFS currently supp orts only

SmartCard.shutdown;

Op enBSD, it is p ossible to p ort it to other

} catch Exception e {

UNIX systems, and p erhaps even to Windows

e.printStackTraceSystem.err;

NT.

}

Sp ecial Purp ose Standards

System.exit0;

Application sp eci c standards such as

}

PKCS11, EMV, and SET have advan-

}

tages in usability in sp eci c domains b ecause

of higher abstractions than SCFS. In SCFS,

The example co de is easy to understand for

functionalitytotake advantage of smartcard

those familiar with Java. Programmers can

security, suchasinternal and external authen-

take advantage of the higher abstraction of

tication, is given by the pioctl system call.

Java, such as I/O streams, etc. OCF is inte-

However, pioctl is not as user friendly

grated with JavaCards, providing a consistent

as the functionality provided byPKCS11,

developmentenvironment for application soft-

EMV, and so on. Wemay provide libraries for

ware and on-chip software.

sp eci c purp oses to wrap around SCFS to give

However, the reliance on Java can also b e

higher abstractions.

viewed as a disadvantage. Java and its ob ject

oriented mo del mo dularize and simplify com-

plex software, but a smartcard is a simple, pas-

5.2 Advantage of SCFS

sive device. For many smartcard applications,

Java might b e viewed as overkill.

Transparent API with the UNIX Filesys-

In SCFS, we use a smartcard in a simple way.

tem

For example, we can print out a le as in the

SCFS di ers from the other approaches suchas

OCF example bytyping:

OCF and PC/SC b ecause it is implemented as

mount_scfs /dev/scfs0 /smartcard

an op erating system extension. Consequently,

cat /smartcard/id

to an application, smartcard les lo ok identical

to les stored on other media. With SCFS, an

OCF cannot b e used with languages such

application can use a smartcard without mo d-

as C and C++, the languages in which most

i cation Figure 5.

op erating systems and security proto cols are

written. Consequently, OCF o ers little to en-

Application Application

hance directly the security of many op erating

y proto cols, such as UNIX,

systems and securit OS OS SCFS

Kerb eros, and SSH.

Figure 5: Application is not mo di ed to

PC/SC

use SCFS.

PC/SC is a general purp ose architecture for in-

tegrating a smartcard into PCs [3]. Its ob jec- If we purchase the Installable Filesystem package.

Smartcard Filesystem 9

With SCFS, many UNIX applications can kinds of abstraction may b e required. There-

take advantage of smartcard security without fore, there are many standards that do not in-

mo di cation. For example, here is howwe terop erate [1]. In contrast, SCFS works with

made SSH work with a private key stored in araw smartcard with a minimum amountof

a smartcard: we added a symb olic link from abstraction; no matter what application is on

$HOME/.ssh/identity to /smartcard/ss/id a smartcard, SCFS can access the smartcard.

and copied a private-key to the SSH identity SCFS allows users to access a smartcard with

le. sophisticated UNIX commands, suchascd, ls,

pwd, cat, etc. SCFS is esp ecially helpful in

citi mount_scfs /dev/scfs0 /smartcard

maintenance, testing, and debugging; Figure 7

citi ln -s /smartcard/ss/id

depicts our mo del of SCFS as a development

~/.ssh/identity

to ol.

citi ssh sin.citi.umich.edu

Enter PIN: Application Development

sin logout Application

et, Kerb eros tickets and

Although not tested y OCF PC/SC EMV PKCS#11

Netscap e co okies can b e stored in SCFS in sim-

ilar ways.

Smartcard

In contrast, OCF or PC/SC require that an

Maintenance, Test, Debug

application b e mo di ed to use a smartcard b e- t from

cause the API for a smartcard is di eren SCFS

the API for normal les Figure 6.

Figure 7: SCFS as a low-level develop-

Application

ment to ol. Application OCF or PC/SC

OS OS

Figure 6: Application must b e mo di ed

6 Future Directions

to use OCF or PC/SC

Some ideas derived from other smartcard

standards suggest enhancements to SCFS. In

PC/SC, a smartcard sp eci c driver is loaded as

Portability

a DLL Dynamic Loadable Library. In SCFS,

smartcard sp eci c co de is directly written in

Another advantage of SCFS is p ortability.

the user-level application, scfsd. PC/SC's ap-

Most of the SCFS co de is in user space and

proach is more extensible than ours b ecause it

easily p orted to other op erating systems. The

do es not require recompilation to add a driver

xfs kernel mo dule is based on Arla, whichis

for a new smartcard. We are considering ex-

already p orted to many UNIX-like op erating

tending SCFS to have the same advantage by

systems, including Solaris, NetBSD, FreeBSD,

reading con guration information from a table.

Op enBSD, Linux, AIX, HP-UX and Digital

Weintend to p ort SCFS to di erent op er-

UNIX. It is easy to p ort SCFS xfs to other

ating systems and to supp ort more smartcard

op erating systems.

typ es. Currently it supp orts only Schlum-

b erger MultiFlex, Cyb erFlex, and PayFlex.

5.3 SCFS as DevelopmentTool

Security of SCFS should b e explored. SCFS

is currently vulnerable to Tro jan Horse attacks, Smartcard standards other than SCFS give

i.e.,ifanadversary has administrative privi- higher abstractions for users, e.g. Java lan-

leges, she can install a rogue version of SCFS guage in OCF, EMV'96 for electric commerce,

that steals a user's PIN or mo di es contents of PKCS11 for cryptographic applications, etc.

the smartcard. We are investigating integrity Dep ending on the typ e of applications, di erent

10 itoi

systems, part 1-8, December 1997. checking and authentication of SCFS co de by

http://www.smartcardsys.com. a smartcard.

We plan to use SCFS in several applications.

[5] Europay, MasterCard, and Visa. Emv'96:

One of them, storing Kerb eros tickets, is par-

Integrated circuit card application sp ec-

ticularly interesting, as it dovetails with our

i cation for payment systems, June

related Kerb eros V5 smartcard extensions [10].

1996. http://www.mastercard.com/

In that application, the smartcard p erforms de-

emv/emvsp ecs02.html.

cryption on Kerb eros tickets. Storing the result

in a protected SCFS le indicates the synergy

[6] Scott B. Guthery and Timothy M. Ju-

of our approach.

rgensen. Smart Card Developer's Kit.

MacMillan Technical Publishing, Indi-

anap olis, Indiana, Decemb er 1997.

7 Conclusion

[7] R. Hermann, D. Husemann, and

Wehave implemented a Smartcard Filesystem

P. Trommler. Op encard framework

SCFS to ease development of smartcard soft-

1.1 programmer's guide, Oct 1998.

ware. SCFS provides a UNIX lesystem API

http://www.op encard.org/do cs/pguide/

for a smartcard. Develop ers can use the well-

PGuide.html.

established UNIX API and developmentenvi-

ronment to develop smartcard software. Per-

[8] Reto Hermann, Dick Huseman, and Peter

formance evaluation shows the overhead caused

Trommler. The op encard framework. In

by SCFS is negligible.

CARDIS'98, Louvain-la-Neuve, Belgium,

Sept. 1998. Third Smart Card Research

and Advanced Application Conference.

8 Acknowledgment

[9] The International Organization for Stan-

We thank the Arla develop ers: Assar Wester-

dardization and The International Elec-

lund, Love Hornquist-Astrand, Magnus Holm-

trotechnical Commission. ISO/IEC 7816-

b erg and many more p eople in the arla-drinkers

4 : Information technology - Identi cation

mailing list for patiently answering our ques-

cards - Integrated circuits cards with con-

tions.

tacts, 9 1995.

[10] Naomaru Itoi and Peter Honeyman.

References

Smartcard integration with kerb eros v5.

Technical rep ort, Center for Information

[1] Duncan W. Brown. Application de-

Technology Integration, Dec. 1998. CITI

velopment: A new fo cus for smart

Techrep ort 1998-8.

card suppliers and implementaters. In

CardTech/SecureTech'98,volume 1, pages

[11] S. R. Kleiman. Vno des: An architecture

352{353, Washington, DC, April 1998.

for multiple le system typ es in sun unix.

In Proceedings of USENIX Summer Tech-

[2] Op enCard Consortium. General in-

nical Conference. USENIX, 1986.

formation web do cument, Oct. 1998.

http://www.op encard.org/do cs/gim/

[12] RSA Lab oratories. Pkcs 11:

o cfgim.html.

Cryptographic token interface stan-

dard. version 2.01, December 1997.

[3] Microsoft Corp oration. Smart

http://www.rsa.com/rsalabs/pubs/PKCS/.

cards, white pap er, April 1998.

http://www.microsoft.com/ smart-

[13] Marshall Kirk McKusick, Keith Bostic,

card/smartcards/scardwp.asp.

Michael J. Karels, and John S. Quarter-

man. The Design and Implementation of [4] PC/SC Workgroup Microsoft Corp.

the 4.4BSD Operating System. Addison- etc.. Interop erability sp eci ca-

Wesley Publishing Company, 1996. tion for iccs and p ersonal computer

Smartcard Filesystem 11

[14] SUN Microsystems. Java card technology.

http://java.sun.com:80/pro ducts/javacard/

index.html.

[15] Multos. http://www.multos.com/.

[16] Jim Rees. Iso 7816 library, 1997.

http://www.citi.umich.edu/pro jects/sinciti/

smartcard/sc7816.html.

[17] James F. Russell. Compatibility and con-

icts: Pc/sc, o cf, java card, multos ... In

CardTech/SecureTech'98,volume 1, pages

97{101, Washington, DC, April 1998.

[18] Assar Westerlund and Johan Danielsson.

Arla - a free afs client. In Proceedings of

USENIX 1998 Annual Technical Confer-

ence, pages pp. 149 { 152, New Orleans,

Louisiana, USA, June 1998. USENIX.

http://www.stacken.kth.se/pro jekt/arla.