<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-C7150120-74C2-5FF1-99F0-0A267393E342" xml:lang="en"><title>CryptoToken
Framework Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>CryptoToken framework provides interfaces for managing cryptography certificates,
keys and certificate applications. </p>
<section id="GUID-4FBED09A-C3D8-4A0C-8417-719D3556166A"><title>Purpose</title> <p>Cryptography certificates, keys and certificate
applications are known as tokens. </p> <p>The framework provides interfaces
that must be implemented to support the storage and retrieval of specific
types of tokens. </p> <ul>
<li id="GUID-EF990C8D-8D16-5C30-B67F-064E0E509BC9"><p><xref href="GUID-064302D7-3598-57C2-89B7-CED294BE78AE.dita"> Certstore
framework</xref> - Provides interfaces for implementing certificate stores </p> </li>
<li id="GUID-F3DABDF6-7D50-5932-B5EA-99A2ABEE6791"><p><xref href="GUID-8D4F44CB-0B4D-51EE-A2D7-A1BBB3DD326A.dita"> Keystore
framework</xref> - Provides interfaces for implementing keystores </p> </li>
<li id="GUID-546CB6FA-096B-5869-8CDC-5BD5D2422F58"><p><xref href="GUID-44345B7F-77DE-5D00-BA0B-BFE40E664DA8.dita"> Certapps
framework</xref> - Provides interfaces for implementing certificate application
stores </p> </li>
</ul> </section>
<section id="GUID-7E139AE3-08FA-404D-9E93-68730358BD8F"><title>Key concepts and terms</title> <dl>
<dlentry>
<dt>Token</dt>
<dd><p>A token is a physical instantiation of an object, such as a certificate
or a key, stored in a phone. Each token belongs to a group of tokens called
a token type. For example, an X.509 certificate is a token which belongs to
the X.509 token type. </p> </dd>
</dlentry>
<dlentry>
<dt>Key</dt>
<dd><p>A cryptography key is a constant value applied using a cryptographic
algorithm to encrypt text or to decrypt encrypted text. </p> <p>Keys are classified
as symmetric and asymmetric based on the type of algorithm applied. If the
same key is used for both encryption and decryption, it is symmetric. If different
keys are used for encryption and decryption, they are asymmetric. Asymmetric
keys exist in the form of a public and private key pair, where the public
key is used for encryption and the private key is used for decryption. </p> </dd>
</dlentry>
<dlentry>
<dt>Certificate</dt>
<dd><p>A certificate (or Public Key Infrastructure (PKI) certificate) is an
electronic document that binds an identity to a public key. It is used to
authenticate public keys. </p> <p>Certificates are issued by a certification
authority (CA) and usually include information such as a label, serial number,
validity period, certificate format (for example, X.509) and algorithm type
(for example, RSA). </p> </dd>
</dlentry>
</dl> </section>
<section id="GUID-2F9E9817-F4DE-4EE7-8059-4A3CEA566760"><title>Architecture</title> <p>The CryptoToken framework provides
interfaces that must be implemented for managing tokens. </p> <p>On
the Symbian platform, applications use the Unified Store API to access file-based
stores for managing certificates, keys and certificate applications. The stores
are called <i>certstore</i>, <i>keystore</i> and <i>certapps</i> respectively.
For more information, see <xref href="GUID-0F4DE9E0-4A98-5914-9AB1-DD6CE1A5A1F3.dita">Unified
Stores</xref>. </p> <p>Device creators can use the interfaces provided by
the framework to create their own implementation for managing tokens. </p> <p>In
the following diagram the yellow blocks represent the components provided
by Symbian and the blue blocks represent components that must be implemented
by device creators. </p> <fig id="GUID-4E6F27B8-FEDF-5105-8CFA-A1F9E5C3AF46">
<title>              CryptoToken Framework Architecture            </title>
<image href="GUID-260E0D27-DCC3-52D5-A7E1-36152A04B7C6_d0e594061_href.jpg" placement="inline"/>
</fig> </section>
<section id="GUID-94D27027-0298-4B0A-AE66-52730C308B1C"><title>Key classes</title> <table id="GUID-E20091F3-7CF9-53CB-A0E7-A91008E2BD6F">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<thead>
<row>
<entry>Classes</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><p> <xref href="GUID-33370455-4210-304F-A780-D8F0DD4E1580.dita"><apiname>MCTToken</apiname></xref>  </p> </entry>
<entry><p>Represents a token corresponding to physical instantiation of an
object present in the phone such as a certificate or a key. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-074375B2-8C22-34AE-BD89-CE8E77A7999B.dita"><apiname>MCTTokenType</apiname></xref>  </p> </entry>
<entry><p>Provides an interface for handling types of token which correspond
to a group. Clients access the framework using this class. </p> <p>The difference
between a token type and a token is best explained with an example. Suppose
a device has two identical Wireless Identity Module (WIM) slots, the code
to handle WIMs can be a token type. The token type can have two tokens for
the two WIMs. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-686A1AB3-EF35-3D85-8062-6E99CEDD27A1.dita"><apiname>MCTTokenInterface</apiname></xref>  </p> </entry>
<entry><p>Provides an interface for implementation of an appropriate token. </p> <p>This
class provides functionality to interact with the token's reference counting
framework. (Interfaces themselves are not reference counted, but the token
must remain open while it has open interfaces.) </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-A3A4CA5B-6730-3149-9521-3ADE431B91D4.dita"><apiname>MCTTokenObject</apiname></xref>  </p> </entry>
<entry><p>Manages references to a particular token object. </p> <p>A token
object represents a one-to-one mapping with a corresponding token. It helps
to identify the token through its attributes (for example, its label or token
type) and provides a reference to the token that can be passed between different
processes. </p> </entry>
</row>
</tbody>
</tgroup>
</table> </section>
<section id="GUID-CD300AAE-01FD-42BD-BA48-C4CE2474B760"><title>Typical uses</title> <p>Crypto Token Framework provides standard
interfaces for implementing the following: </p> <ul>
<li id="GUID-A1ABA8A1-544C-5120-8C3C-1FD01973106B"><p> <i>Certstore</i>, <i>keystore</i> and <i>certapps</i>.
For details, see <xref href="GUID-C3290344-486B-554D-97FC-42DF48E150AA.dita">Certificate
and Key Management</xref>  </p> </li>
<li id="GUID-FFA4443B-6DD6-5C84-AE18-4C33DC8997D0"><p>File based tokens which
stores certificates, keys and applications associated with certificates in
file format in the phone. For details, see <xref href="GUID-A5DCCEB1-77DA-53C9-A1A3-07615DFCD403.dita">File
based certificate and key store</xref>. </p> </li>
</ul> </section>
</conbody><related-links>
<link href="GUID-39B459CD-8210-59B5-95F4-85CE36676735.dita"><linktext>Unified Stores</linktext>
</link>
<link href="GUID-A5DCCEB1-77DA-53C9-A1A3-07615DFCD403.dita"><linktext>File-Based
Certificate and Key Stores</linktext></link>
</related-links></concept>