Get documents about "SmartCard-based Multi User Security Concept for Mobile Devices
Document Sample
SmartCard-based Multi User Security Concept
for Mobile Devices
STEFFEN OLDENBURG1 , CLEMENS H. CAP2
Chair for Information and Communication Services
Department of Computer Science
University of Rostock
Albert-Einstein-Straße 21, D-18059 Rostock
Germany
Abstract: Powerful mobile devices are typically used by single users, but can also be used in multi-user scenarios
where off-the-shelf devices fail to provide the security features needed for e.g. user specific logins for device or
context-sensitive application access. This paper presents a new approach to combine a transparent smartcard-based
secure access to mobile devices and applications on them with context-enabled, profile-based security. A security
service on the device including a proxy model secures and synchronizes client and card access and enables an
on-card information management for applications. It establishes the basis for an identifying user logon and for an
authorised application access. Current results and future perspectives of the reference implementation on an iPAQ
PDA running Windows CE are presented.
Keywords: Mobile Devices, Smartcard Authentication, Access Control, Trust Management
1 Introduction 2 Problem Formulation
2.1 Multi user security
During recent years mobile devices have become pow-
erful small computers. Their functionality ranges from Confidentiality and integrity: Sensitive private or
smart phones or PDAs to full featured laptops. They business data on the device or a mobile storage means
provide connectivity to the environment and synchroni- can be protected from unauthorised access using encryp-
sation features with other devices. tion mechanisms. Individual cryptographic keys have to
The main focus of this paper is placed on the device be securely stored, e.g. on the PDA itself wrapped in
type Personal Digital Assistant (PDA). PDAs are com- a locally stored security container, e.g. as used in Win-
monly used by a specific person in single user scenarios, dows CryptoAPI. Hence they are bound to the local de-
however, here the emphasis is put on the fact that the de- vice and inflexible in use. A possible theft or loss could
vice can be seen as some kind of service provider, which compromise sensitive data3 . Device independent user
allows several persons to use the same device in parallel specific cryptographic features are needed.
or sequentially. An example is the usage of the PDA in a
hospital environment with stationary and mobile health Identities and roles: In order to be granted or denied
care [9, 17]. This and similar scenarios have in common the right to access a mobile device or an application
the shared operation of the mobile device due to high on it different users must be identified in a secure and
costs or more efficient working. unique manner. This can be achieved with a logon ser-
A single user mostly expects a device protection vice on the device requesting user credentials uniquely
against unauthorised access and is in need of confiden- identifying the user in the desired context. A multi user
tial data storage and a secure data transport to and from PDA furthermore also needs protection between differ-
the device (see [22, 18, 20]) to prevent information theft 3
According to TECS 31.08.2001 2900 laptops, 1300 PDAs und
or tampering [17], but a shared operation poses further 62000 cell phones where left in London’s taxies in the first half of
security questions. 2001.
1
ent users on it which possess distinct tasks and respon- Login interface: Windows CE provides a simple
sibilities. generic interface for a local device login via an exclu-
A physician in the context hospital may prescribe sive control panel library, preventing other applications
medicine and decide about its dose, while a nurse is only from being started while active. The login can be dis-
allowed to administer the medicine and record this ac- abled in the system properties. The login credential is
tion. They are entitled to different actions on the same valid for all device users, there is no distinction between
data objects (same application) due to different roles different roles.
(see [6]).
Exceptional behaviour: A secure system access must
even be guaranteed in exceptional situations like a hard
Authenticity and availability: Persons accessing re-
and soft device reset, loss of power, system shutdown
sources must prove their authenticity. Unauthorised ac-
due to power saving or a theft. Longer periods of user
cess must be prevented, authorised access must not be
abscence can be limited by timeouts requiring the user
hindered. The availability of a multi user PDA must take
to relogin.
into account the individual user roles.
Security solutions Several security solutions for the
Non-repudiation: The originator of a specific secu- PDA perform one or more of the features given, for ex-
rity related action in a multi user scenario should beamples see [17, 22].
inevitably identifyable. Context-based security profiles They all are a static, device-bound security exten-
for users and applications, combined with user bound sion for access control which, however, cannot respond
cryptographic keys, e.g. for signatures, are needed. dynamically to context changes. A second problem is
that they do not consider a greater number of device
users with different roles. Commonly an admin and a
2.2 Shortcomings of mobile security user are distinguished. Profiles, if available, are typi-
Currently the most used PDA OS is Windows CE which cally assigned for users only and are rarely integrated
lacks several security properties under the aspect of into an overall security solution which provides a so-
multi user operation. phisticated, flexible policy management including all re-
lations between user, device, context and applications.
Identification and access protection: In a desktop
Windows system every user is assigned an Access To- 3 Problem Solution
ken after successful login which contains information
about the user and is used for the identification during 3.1 Targets
an access request to a Securable Object. Such objects, Token-based access protection: The login concept
e.g. files and memory mappings, acquire a Security De- must enable different users to get an identifying, indi-
scriptor which contains Access Control Lists defined by vidual access to the desired PDAs and the applications
the object creator. on them. This requires the login parameters to be in-
However, a Pocket PC only utilises a non- dependent from a user specific device. They must be
identifying, (alpha)-numeric password which can be in- portable, securely accessible and stored tamper-proof.
serted incorrectly as often as desired. This protection There should be a limit for wrong authentication tries.
enables full or no access at all. No granularity is pro- An external token-based authentication using smart-
vided to lock specific information, access tokens and se- cards meets this requirement. Sensitive data like a PIN
curity descriptors do not exist. is expected to be securely transferrable between device
As part of a so-called Trusted Application Model and smartcard.
the Original Equipment Manufacturer (OEM) can im- Windows CE has support for smartcards and crypto-
plement and activate a Load Time Signature Verification graphic tokens using the WinSCard API where security
feature which results in a signature based access protec- related functions are available using specific providers.
tion for applications using trust levels in order to grant However, sensitive information is typically transmitted
or deny the user to launch an application or to perform in clear text to and from smartcard, selected attacks are
a system call [26]. studied in detail in [12, 23].
2
Context awareness: Both the mobile operation in dif- ing their abilities and restrictions before they receive
ferent contexts and the use of smartcards for access pro- profiles.
tection reveal exceptional cases. An example could be
leaving beyond some defined distance between device Users and context: Due to different tasks and profes-
and smartcard (system log-off after smartcard ejection), sional qualifications users in a context should be able to
device and context (leaving a lab with access to specific access only such local and remote information they are
sensitive data and applications), user and context (leav- entitled to. In order to achieve an overall device access
ing hospital after finishing work) as well as user and de- while lacking a user management for PDAs user spe-
vice (user leaves device unattended). cific profiles must be interpreted according to a context
Context changes must be reflected in adapted access description.
rights depending on access restrictions and requirements This paper proposes smartcards to be used for a
concerning the current user and applications accessible portable storage of context-related profiles. Default con-
via the PDA. texts have to ensure access protection if no profile is
available (offline operation).
Security interface: Cryptographic features include
encryption and digital signatures as well as the safe stor- Applications and context: Applications can be clas-
age of security parameters like keys and profiles. Ap- sified concerning their context awareness. This paper
plications using this concept need to access further se- relates to security relevant applications, which need to
curity functions using a well defined interface. Any handle confidential information like access parameters
sensible information exchange between applications and and need to be informed about context conditions.
the smartcard must be secured. The security concept Applications need a different level of protection,
should be portable to different types of smartcards meet- some only locally, others may process remote and local
ing minimum requirements. profiles. The third kind refers to remote profiles only
and only needs credentials for remote access (stored on
smartcard). This paper mainly addresses the local pro-
3.2 The PDA in its context
tection.
The mobile device operation occurs in changing con- A security mechanism matching application require-
texts, e.g. a hospital. The term context should be com- ments against user rights is not a typical part of operat-
prehended as the ”set of environmental states and set- ing systems in ressource limited mobile devices. This
tings that either determines an application’s behaviour deficiency will be replaced with a dynamical access con-
or in which an application event occurs and is interest- trol, performing a matching between context, user and
ing to the user” [7]. Applications respond to the environ- application, similar to [10], but using security tokens.
mental state showing a situative behaviour, e.g. a state
transition. Profiles and context: Context-compatible profiles
Physical properties of a context comprise location link applications, users and contexts. The context can
and time or existing hardware (sensors) to interact with. store application profiles in a server located database.
Logical properties include services available for clients, Every context approved application has a unique ID in
e.g. remote software on a server, but also local applica- the context which also identifies it in the server database.
tions on the PDA. The ID and context specific access attributes are part
A context can be subdivided and distributed over of the application profile on the PDA. The attributes de-
different locations (granularity), contexts may be immo- fine which roles and restrictions have to be applied for
bile (e.g. hospital buildings) or mobile (e.g. hospital accessing the application or an application feature.
emergency car). The private use at home is another con- We propose to use a role-based approach to describe
text. profile contents. An example of a context description
An information exchange takes place with environ- language is presented in [21], which proposes a context-
mental sensors (context sensing) and services (context extended RBAC-model. Our model uses a role concept
reasoning, ad-hoc services) of the context. for persons working in the context, assigns necessary
A multi user context contains interfaces between identities and rights (user profile) to them and deter-
users (identities), PDAs and contexts. User identities are mines which applications define which access restric-
predefined here because users must be verified concern- tions (application profile). Upon an access request there
3
is to check if the requesting person (skills and restric- vice has access to context information, either by sensing
tions in profile) owns the execution rights needed to ac- the context itself or via information from a context ser-
cess the application or an application feature in the cur- vice. Security relevant applications need a secure infor-
rent context. mation exchange with the smartcard or the service. This
The Windows CE system cannot perform such includes loading sensitive data like login passwords or
checks at all (most off-the-shelf devices can’t) or has secret keys from the smartcard as well as service related
a static access model according to OEM-security using requests by a client, e.g. an execution of cryptographic
an unflexible application signature scheme. The con- functions.
text related approach proposed here requires a dynamic
adaptation of access. 3.3.1 Communication model
The smartcard hosts a corresponding
administration-signed security profile of the application The service enables a smartcard-based communication
(same ID, includes application specific credentials). model to achieve a secure communication between ap-
Access is controlled using the smartcard PIN or derived plications, service and smartcard. The encapsulation
data. from the remaining system communication results in a
Upon an execution the application integrity is ver- closed, secured environment which only allows a com-
ified (file signature in profile) by the security service. munication via the service and with verification of pro-
The service also compares the context and role / skill files in contexts.
restrictions (part of application profile) against the cur- The concurrent access of several clients needs to be
rent user. synchronised. The use of security parameters stored on
a smartcard and the required sign-on to it enable a user
Context transparency: While security profiles can be specific security environment.
centrally verified in wired environments this is typically The service provides the functionality for user au-
impossible in ad-hoc networking. A central security ver- thentication, application and card control. The follow-
ification may be optional in many contexts. An offline ing functionality is essential.
operation should be secured using default profiles if no
context is available. A central context database may Device access: For an identifying device access
be replaced by distributed context knowledge in ad-hoc the user has to successfully enter his user specific,
scenarios. smartcard-bound and secret PIN into an uncircum-
ventable login dialogue. The smartcard login replaces
Scope and research contribution: The paper cur- the former non-identifying default login.
rently assumes the existence of a role concept in the con- A secure transmission of the PIN to the smartcard
text, e.g. RBAC [13] and adaptations of it like General- is needed which cannot be successfully eavesdropped
ized RBAC [11] and context enabled RBAC [19], and an by a man-in-the-middle for a later abuse to fake digital
appropriate context modelling language [21]. It’s cur- signatures etc.
rently not intended to manipulate the operating system
on the PDA or to develop a new one from scratch.
Card selection: The card must support a safe host-
The research contribution is the combination of the
to-card communication using secure messaging mecha-
secure environment of security tokens (smartcards) with
nisms [14, 15, 23]. Furthermore the storage of applica-
a profile based security concept. This paper deter-
tion specific profiles requires a sophisticated file struc-
mines specific requirements to such an architecture and
ture, which requires a smartcard supporting the creation
presents a security middleware prototype for the mo-
of a user defined file system extension.
bile device which is used to evaluate the suitability of
the PDA system for this security concept and to identify
necessary modifications. User secrets: The secure card connection cannot be
negotiated safely by most existing smartcards.
In our transparent model every user needs a key
3.3 Service architecture
store to be created for him and stored on his smartcard.
The idea is to bind security related applications as a The store contains communication keys which also need
client to a local security service on the device. The ser- to be configured on the smartcard as card system specific
4
keys. These keys control encryption and integrity in the Smartcard provider: The card service should be en-
host-card communication. abled for a flexible and transparent integration of differ-
The keys must be generated as part of a smartcard ent card types. Therefore the card access model com-
customisation by the context administration. They never prises a card monitor, a card manager, card specific card
leave the card and can be changed by the user in a se- providers and a parametric generator for APDUs4 .
cure manner using the security service on the PDA. New The monitor maintains the card connection and noti-
keys are transferred to the card secured by the old keys fies the service about state transitions (e.g. card present
to be replaced. The keys are protected in a reflexive way, event). Ejecting the card results in a lock of the PDA.
hence they can only be accessed after a successful veri- An initially established connection activates card recog-
fication of the same key. The store key is derived from nition and configuration (recognized provider). The
the PIN. manager ensures a correct APDU-based card commu-
nication. Each card provider is derived from a generic
provider (overall functions) and adds card specific com-
Login protocol: The secure login verification work- mands. The (in)secure connection is transparent to the
flow consists of the parts PIN entry and key derivation, user, APDUs are generated by an APDU generator.
loading and extracting the key store including a signa-
ture verification to prevent from store tampering, select- 3.3.3 Application access
ing the signature application on card, initialising the se-
Applications in this model may be fully or partially ac-
curity environment on device (key numbers) and card
cessible. A fine-tuned granular comparison between re-
(service) without any key exchange and the final safe
strictions and role based rights may be needed.
PIN verification itself.
Applications subdivide into three different types.
Container transport and key initialisation can be
Type 1 requests its execution right from the service each
communicated in clear with the smartcard. A secure
time it’s executed (locally client-oriented).
communication is enabled due to common knowledge of
Type 2 receives its access configuration from the ser-
the keys between security service and smartcard without
vice which dynamically adapts system shell and visibly
the need to exchange them.
accessible applications to the level the currently logged-
This mechanism can be applied to several cards in user is authorised to. Thus even current PDA appli-
which meet the card selection requirements. It achieves cations which are not related to this model can be inte-
a better security over common exchange schemes [12]. grated using profile entries for legacy applications. This
is a locally service-oriented view (kiosk mode).
Type 3 addresses applications which are executed on
3.3.2 Smartcard access a remote server or another device in a distributed envi-
ronment while the PDA has the role of a terminal client.
For a secure and consistent smartcard control the se-
All access right checks and dynamic shell configurations
curity service needs an exclusive card connection with-
are done by the server (remote service orientation).
out any other application interference. The connection
The current work analyses the first case. It’s the
bases on the smartcard interface of the operating sys-
most easiest to realise because no new system shell is
tem. The service controls access to this interface with
needed.
a local smartcard component, which takes care for a se-
cure smartcard connection.
Client authenticity: Clients must register with the
A proxy is responsible for a synchronised and se-
service in a registration protocol to get known to the
rialised application (client) access with smartcard- and
model. An integrity check ensures that only authorised
service related requests. Parallel requests are commu-
application files may use service functions. The check
nicated with the service without any client having to
is essential because the service has full control over the
consider a secure connection management. This has ad-
card connection. It is aware of the secure messaging
vantages in that way that clients don’t need knowledge
security parameters and must be able to rely on client
about the specific card (control, security), the context
authenticity. A client must not be able to pose a mali-
(state changes) and other clients, accessing the card at
cious request like an intentional deactivation of the PIN
the same time (synchronisation of smartcard environ-
4
ment for each client). Application Protocol Data Units
5
which would turn a digital signature card useless. The binding to Microsoft CSP should be avoided for secu-
context administration has to make sure the authenticity rity reasons and the limited CSP interface5 .
of clients deployed in the context. The hardware extension comprises a two-slot Com-
paq jacket and a Schlumberger Reflex20 PCMCIA card
Client access: Every client authorised to operate in reader.
the context is associated with an administration signed A security evaluation of the system revealed that no
profile which can be verified by the service. OEM features are enabled and applications have maxi-
Prior to a service request the client retrieves its client mum access rights, e.g. unrestricted executability of ap-
store from the card (proxy) and extracts its private sig- plications or the right to access a memory slot of another
nature key (analogous to service key store). The key process.
signs a registration request to the service which is ver-
ified using the public client key (extracted as clear text 4.2 Smartcard integration
by service from requested client store).
A signed encrypted request proposes a session key The specific smartcard interface libraries are not part of
to be used for client service communication. The ser- the iPAQ system and must be compiled for the Stron-
6
vice processes the queue and informs a queued client to gARM platform . Windows CE only provides an exclu-
transmit its request data, processes the request (e.g. read sive card access using a PC/SC interface to one appli-
from or write to card) and returns the response. All this cation at a moment which corresponds to the service’s
is secured by the encrypted session. exclusive access.
The key is based on a PIN entry required for starting
the application. Card selection: It should be possible to access differ-
ent smartcards and benefit from the available smartcard
Communication: Clients access the card via a ser- security to secure a smartcard communication. Secure
vice interface. This requires an inter process commu- messaging [14] is used to achieve this enabling a secure
nication model which determines an efficient, synchro- byte transfer between host and smartcard.
nised request protocol clients have to abide to in order The card selection requirements mentioned in 3.3.1
to successfully send requests to the service. An appro- are met by the TeleSec digital signature card running
7
priate simple processing strategy for registered (waiting TCOS v2.0 R3, a widely used chipcard operating sys-
queue) requests is a FIFO model without priorities. tem [4, 25]8 .
The service can provide additional functions which
may not need card access due to missing support by the Card configuration: After delivery (e.g. from a trust
currently inserted smartcard, e.g. a cryptographic func- center) the context administration can extend the smart-
tion. This results in a fully transparent client interface. card with an own file structure (typically additional files)
below the root directory. It contains a separate service
Card configuration: An appropriate on-card file file structure (Dedicated File) as well as necessary keys
structure for this model extends the existing file system for secure messaging between host and smartcard, here:
with a directory for the security service hosting the ser- two keys EFM AC , EFCipher for message authentica-
vice key store and a dedicated file for each client. tion and encipherment. They are protected against unin-
tended administration by a reflexive administration key
EFSrvKey for mutual authentication with the chipcard,
4 Implementation not known to normal context users. The next level in the
file structure is covered by the key store file (Elementary
4.1 Reference environment File) for secure messaging configuration and seperate
The concept should be deployable on different types of 5
The required encryption functionality can mostly be derived
PDAs running Windows CE. A smartcard integration is from the open source RSAEuro toolkit [1].
6
available starting with Windows CE 3.0. Due to its per- A library creation essentially requires Microsoft Platform
formance and extensibility a Compaq iPAQ 3660 run- Builder 3.0.
7
TeleSec Chipcard Operating System
ning Windows CE was chosen as the reference platform. 8
Due to its security properties (e.g. ITSEC level 4) the smart-
The prototype is not based on higher versions of card can be used in accordance to the German Digital Signature Law
Windows CE including smartcard providers. A strong (SigG) for digital signature applications [24]
6
DFs for each client (created through successful registra- could spy the coordinates of PIN numbers which can be
tion with the service) which are secured by EFSrvKey associated with the numbers entered.
(e.g. against deletion) and against unintended reading Due to missing OEM security of the standard iPAQ
and update operations by EFM AC and EFCipher . device the examination of an application’s memory
The key store consists of a secret part being en- space is not prevented, thus enabling to read secret infor-
crypted with a PIN-derived key and a public part (salt, mation. After all smartcard proxy, client-service com-
iteration count) as clear text. The integrity is ensured munication components and the login component are
using the card’s signature function. only a system extension and replacement for less secure
components. Only a utilisation of OEM features will
achieve a fully secure system.
5 Conclusion The login interface differs between different ver-
sions of Pocket PC, hence the login integration must be
The security approach extended the reference system
adapted to be portable.
with a security service concept and identified the re-
There is no device protection after a hard reboot, the
sources and interfaces which are needed.
device will have default security after it, however, sen-
A closed secure environment was implemented un-
sitive data is deleted during reboot.
der consideration of some weak points of sthe operat-
ing system. The security is based on a simple sign-on
solution using a card PIN as source for login and key 5.2 Perspectives
derivation. The combination of secure messaging, key
The following aspects show a perspective for future ac-
stores and a confidential communication concept results
tivities and a further concept development.
in a trusted communication environment – a so-called
Trusted Digital Assistant. Requirements for a context
administration were addressed. Security migration from service to smartcard: Cur-
The paper revealed that current signature cards can rently the security functions including secure messaging
be successfully used for safeguarding mobile devices. updates (keys, key store) are integrated into the service
Minimal on-card resources, however, define limits. on the device. This may be a risk due to malicious pro-
grams examining memory for secret material which can
5.1 Problems only be prevented using the inflexible OEM security.
The idea is to migrate all relevant update function-
The multi user login feature was examined using dif- ality for key stores and secure messaging keys to the
ferent login strategies. One issue is whether the system smartcard. New keys can be generated and encrypted
login is part of the service application or separated from into the key store on-card with a PIN-derived key if the
it. It’s essential that the service gains knowledge about PIN is globally known on the smartcard.
the card PIN. A tamper-proof profile verification could be imple-
Subsequentially the login must be a part of the ser- mented on-card as well, but requires a strictly resource-
vice which has exclusive card access. But an integrated saving verification mechanism. The advantage of this
login (system and ActiveSync) is only available if ini- approach would be a transparent device- and platform
tiated by the system during autostart9 . Hence the lo- independent portable security code.
gin can either be realized as a specific control panel or
the service itself is part of the control panel. This does
Smartcard memory extensions: On-card profiles
not allow for background smartcard and security moni-
must have a minimal size. Specific context evalua-
toring, because the login application is terminated after
tions are likely to reveal, that a typical card’s space is
successfull code entry. An alternative login full screen
not sufficient to host all key stores and profiles needed.
can be realised but needs a permanent background mon-
Memory extensions are needed. External network-based
itoring thread, because any system event can send the
memory extensions are proposed in [5, 2]. But in
screen to background.
dynamic context-based scenarios a permanent network
The PIN insertion can be monitored. A probably
availability of the memory server is not guaranteed.
malicious application may be hidden in background and
A context evaluation must examine which profile in-
9
Later not possible due to exclusive execution. formation must be stored on smartcards and which one
7
on a memory card. A memory card supplies a quasi un- is needed as well as its mapping to application and user
limited memory for securely stored data (cryptographic profiles. The context awareness must be secure and au-
container) only accessible via smartcard and an appro- thentic.
priate user profile. Thus profiles are not limited to the
smartcard’s free space. Context-enabled PDA system: Also the mobile sys-
tem has to be context aware. Applications must be de-
Flexible OEM signature hierarchy: The current sig- veloped taking advantage of full or granular security
nature scheme is too inflexible, locally bound to the de- bound to roles. The applications can be on the device,
vice and does not allow for context specific signatures. distributed or on a remote server (terminal concept). A
One approach would be to establish some PKI-like trust portability of this concept to other systems should be
chain, starting with an OEM certificate, which autho- evaluated. Some research results in this field explor-
rises a context administration to derive own organisation ing device movement by distance measurement using
specific certificates to sign authorised applications. An WLAN has already been achieved and will be a basis
user based flexible adaptation of allowed and restricted for a context approach [3].
applications can be based on the signed application pro-
files on the user’s smartcard. References:
[1] Nick Barron. RSAEuro Technical Reference. Technical report,
Remote card access: In order to simplify smartcard Reaper Technologies, 1996. http://www.rsaeuro.com.
access for mobile devices which are often not equipped [2] Patrick Biget. The Vault, an Architecture for Smartcards to
with the extension technology needed (card reader) an Gain Infinite Memory. Technical report, Gemplus Research
approach would be to access a remote smartcard via a Group, 1998. Smart Card Research and Advanced Applica-
tion Conference (CARDIS’98), citeseer.nj.nec.com/
secure channel from the PDA. An appropriate example biget98vault.html.
for remote card access is given in [16] but should not
[3] Ralf Bill, Thomas Mundt, and Clemens H. Cap. Indoor and
be limited to wired or wireless networking but also inte- outdoor positioning in mobile environments, a review and
grate technologies as Bluetooth. The card work station some investigations. 2004. Proceedings of 1st. International
must be secure against adversary attacks on the smart- Workshop on Ubiquitous GIS.
card communication. A second way would be using a [4] J. Breuer, B. Fuchs, and A. Philipp. TeleSec ChipCard Op-
contactless token (MIFARE) or a smart badge in order erating System V2.0 Release 3. Produktbereich T-TeleSec,
to authenticate against the device (research in progress). Deutsche Telecom AG, 2001.
[5] Clemens H. Cap, Niko Maibaum, and Lars Heyden. Extend-
ing the Data Storage Capabilities of a Java-based Smartcard,
Trusted Computing: The evolving TCPA standard 2001. 6th IEEE Symposium on Computers and Communi-
and its integration into PDAs poses questions for a cations ISCC‘01 in Hammamet, Tunesia, citeseer.nj.
more secure hardware based solution. TCPA enables nec.com/460858.html.
PDAs to use device specific information for a verifi- [6] Ramaswamy Chandramouli. A Framework for Multiple Au-
thorization Types in a Healthcare Application System. Tech-
cation whether the device is in a trusted state or not,
nical report, National Institute of Standards and Technol-
e.g. for a device authentication against the user. If ogy (NIST), 2000. http://csrc.nist.gov/rbac/
this scheme can be flexibly configured to use context #intro.
specific, tamper-proof information stored in the TCPA [7] Guanling Chen and David Kotz. A Survey of Context-Aware
chip, a mutually secure authentication can be realized. Mobile Computing Research. Technical report, Dept. of
Therefore the user will request the device to authenti- Computer Science, Dartmouth College, 2000. Technical Re-
port TR2000-381, http://www1.cs.dartmouth.edu/
cate, e.g. against a security token of the user, then the ∼dfk/papers/chen:survey-tr.pdf.
user knows that he can communicate with a trusted, un-
[8] Harry Chen. An intelligent broker architecture for
tampered with device without being compromised. Fur- context-aware systems, 2003. citeseer.nj.nec.com/
ther research in this field is in progress. chen03intelligent.html, PhD. dissertation proposal.
http://umbc.edu/∼hchen4.
Context evaluation: A profound application of this [9] Mobile medical data retrieval in the clinical func-
tion analysis. Technical report, Fraunhofer Insti-
concept in a specific context requires the establishment tute for Graphical Data Processing (IGD), Rostock,
of communication (context sensing, reasoning) and ad- 2000. http://www.rostock.igd.fhg.de/IGD/
ministration structures. A detailed context description Abteilungen/AR3/Projekte AR3/CliF.
8
[10] Michael J. Covington. A context-aware security architecture [25] Torsten Vollmer. Aufbau und Struktur der PKS-SigG-Karte
for emerging applications. 2001. In Proceedings of the Sixth mit TCOS V2.0 Rel. 3. PZ Telesec der Deutschen Telecom
ACM Symposium on Access Control models and technolo- AG, 2001.
gies. [26] Creating a Secure Windows CE Device. http:
[11] Michael J. Covington, Matthew J. Moyer, and Mustaque //msdn.microsoft.com/library/default.
Ahamad. Generalized role-based access control for secur- asp?url=/library/en-us/dnce30/html/
ing future applications, 2000. 23rd National Information winsecurity.asp, 2002.
Systems Security Conference, citeseer.nj.nec.com/
covington00generalized.html.
[12] Armin B. Cremers, Adrian Spalka, and Hanno Langweg. The
Fairy Tale of ”‘What you see is what you sign”’ - Trojan
Horse Attacks on Software for Digital Signatures. Techni-
cal report, Department of Computer Science III, University of
Bonn, 1997.
[13] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, et al. A Pro-
posed Standard for Role-Based Access Control. Technical re-
port, National Institute of Standards and Technology (NIST),
2000. http://csrc.nist.gov/rbac/#intro.
[14] ISO 7816-4, Integrated Circuit Cards with Contacts, Part 4,
Interindustry commands for interchange. ISO/IEC, 1995.
[15] ISO 7816-4, Integrated Circuit Cards with Contacts, Part 4,
Amendment 1, Impact of secure messaging on the structures of
APDU messages. ISO/IEC, 1997.
[16] Naomaru Itoi, Tomoko Fukuzawa, and Peter Honeyman. Se-
cure Internet Smartcards. Technical report, Center for In-
formation Technology Integration (CITI), 2000. Program
in Smartcard Technology: http://www.citi.umich.
edu/projects/smartard.
[17] ITSMed: PDA Security. Technical report, Yale University,
School of Medicine, 2001. http://its.med.yale.
edu/security/PDA/#overview.
[18] Kingpin and Mudge. Security Analysis of the Palm Operating
System and its Weaknesses Against Malicious Code Threats.
Technical report, @stake Inc., 2002. In Proceedings of the
10th USENIX Security Symposium.
[19] Arun Kumar, Neeran Karnik, and Girish Chafle. Context sen-
sitivity in role based access control, 2001. IBM Research
Report, citeseer.nj.nec.com/kumar01context.
html.
[20] Daniel M. Lyon. The Dilemma of PDA Security: An
Overview. Technical report, SANS, 2002. http://www.
sans.org/rr/paper.php?id=257.
[21] Christopher P. Masone. Role Definition Language (RDL):
A Language to Describe Context-Aware Roles. Tech-
nical Report TR2002-426, Dartmouth College, Computer
Science, 2002. ftp://ftp.cs.dartmouth.edu/TR/
TR2002-426.ps.Z.
[22] Handheld Security For The Mobile Enterprise. Techni-
cal report, Palm Solutions Group, 2002. White Paper,
http://www1.cs.dartmouth.edu/∼dfk/papers/
chen:survey-tr.pdf.
[23] Wolfgang Rankl and Wolfgang Effing. Handbuch der Chip-
karten, Aufbau - Funktionsweise - Einsatz von SmartCards.
u
Hanser Verlag M¨ nchen, 1999. ISBN: 3-446-21115-2.
[24] DIN Chipcards with digital signature application / function ac-
cording to SigG / SigV, 1998.
9
Related docs
