This is a long email, but it goes direct to the source, namely RSA Labs.

PKCS #11 is the definition, in the C++ programming language, of an API for
use by an application requiring cryptographic services. The API provides a
common way for the application to connect to a device that holds
cryptographic information and performs cryptographic functions. Typically,
an application within a PC obtains services from a smart card (the token)
inserted in a reader/writer connected to the PC, but PKCS #11 is written in
a general manner, so that, for example, the cryptographic service could be
provided by a remote server.

Cryptographic tokens, such as Integrated Circuit Cards (or IC cards), are
intrinsically secure computing platforms ideally suited to providing
enhanced security and privacy functionality to applications.

As noted by Matthias, PKCS #11 is implemented as a library in a PC. This
library can included drivers for a specific combination of card reader and
card, or, as noted above, it can connect to a network on which is a secure
server.

PKCS #15 is intended at establishing a standard which ensure that users in
fact will be able to use cryptographic tokens to identify themselves to
multiple, standards-aware applications, regardless of the application's
cryptoki (or other token interface) provider. Thus PKCS #15 defines the file
structure within the token (usually a smart card), and therefore also the
skeleton of the 'card edge' interface (the commands used to access the
token). Newly published is information about profiling the card edge and the
card file structure to suit different applications.

From the RSA Labs Security web site:

PKCS #15: Cryptographic Token Information Format Standard
Background
It is widely recognized that cryptographic tokens such as Integrated Circuit
Cards (ICCs or Smart Cards) offer a great potential for secure
identification of users of information systems. But if this potential is
ever going to be fully realized, and users are to receive full benefit of
these tokens, there is an obvious requirement of credential portability and
interoperability.
Interoperability demands standardization, and this document, PKCS #15, is
intended at establishing a standard which ensure that users in fact will be
able to use cryptographic tokens to identify themselves to multiple,
standards-aware applications, regardless of the application's cryptoki (or
other token interface) provider.

Why is PKCS #11 not sufficient?
The PKCS #11 specification alone can not offer this functionality since it
is an API specification aimed at offering applications a uniform interface
to cryptographic tokens. This means that different tokens requires different
PKCS #11 drivers, and unless a user's desktop has the 'right' PKCS #11
driver installed, the user will be unable to use the token on that desktop.

What does 'Information Format for Cryptographic Tokens' mean?
This means that we need to agree on the syntax for storing digital
credentials (keys, certificates, etc) on these tokens, and how this
information are to be accessed. If such an agreement can be met, we have a
very good platform to achieve the goals of this work.

Objectives
Some important objectives of PKCS#15 are:
? Enable interoperability among components running on various platforms
(platform neutral).
? Enable applications to take advantage of products and components from
multiple manufacturers (vendor neutral).
? Enable the use of advances in technology without rewriting
application-level software (application neutral).
? Maintain consistency with existing, related standards while expanding upon
them only where necessary and practical.
Users should be able to use their tokens for identification purposes in all
applications where this is necessary

To download the PKCS standards and PKCS #15 profile specification, start at:
http://www.rsasecurity.com/rsalabs/pkcs/index.html and select the PKCS #
that you require.

>
> ----- Original Message -----
> From: Matthias Bruestle <mlistmbsks.franken.de>
> To: <sclinuxlinuxnet.com>
> Sent: Wednesday, October 17, 2001 3:57 PM
> Subject: Re: MUSCLE SC architecture, puzzled
>
>
> > Mahlzeit
> >
> >
> > On Wed, Oct 17, 2001 at 04:11:39PM +0200, Radovan Semancik wrote:
> > > 1) PCKS#11 - I've understood that this is an application-level API,
that
> > > means API between application (netscape) and some kind of driver. What
> > > is that 'driver', is it resource manager or what?
> >
> > It is a library implementing the PKCS#11 API.
> >
> > > Is it specific to a
> > > smartcard type or may I use the same 'driver' for gemplus and
> > > schlumberger cards?
> >
> > It is specific to a smart card type.
> >
> > > 2) How can a card provide PKCS#11 interface?
> >
> > The smart card does not provide a PKCS#11 API. A library on the host,
> > which communicatates with the card, does this.
> >
> > > If that is the case, what protocol do they communicate? A proprietary
> > > one or some standard?
> >
> > The library can use protocols what ever the smard card understands.
> > So in most cases the commands are exchanged via T=0 or T=1 and the
> > data is put on the card into files, etc.. The data layout of these
> > files could be according to PKCS#15.
> >
> >
> > Mahlzeit
> > endergone Zwiebeltuete
> >
> > ***************************************************************
> > Unix Smart Card Developers - M.U.S.C.L.E.
> > (Movement for the Use of Smart Cards in a Linux Environment)
> > http://www.linuxnet.com/
> > To unsubscribe send an email to majordomolinuxnet.com with
> > unsubscribe sclinux
> > ***************************************************************
> >
>

***************************************************************
Unix Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/
To unsubscribe send an email to majordomolinuxnet.com with
unsubscribe sclinux
***************************************************************

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]