Q1: What is CDSA?
A1: CDSA is the Common Data Security Architecture. CDSA provides an open, cross-platform,
interoperable, and extensible software framework consisting of APIs designed to make
computer platforms more secure for applications such as electronic commerce,
communications, and digital content.
Q2: What role did Intel play in developing
CDSA?
A2: Intel Architecture Labs developed specifications for CDSA and then worked with our
collaborators like IBM and Netscape to further refine it within The Open Group standards
process.
Q3: Why does the world need PC security
architecture from Intel arent there good solutions in place now?
A3: Today, many security solutions exist for different aspects of the security problem.
Every independent software vendor (ISV) has to deal with integrating security features
into their applications. Often, ISVs design solutions that do not interoperate with
applications from other ISVs. CDSA unifies multiple security approaches and when used as
directed will provide interoperability between different applications that build security.
There are a variety of cryptography and security
related standards currently in the market. CDSA provides a common specification for
managing the various security related services embodied in these and other security
standards.
Q4: How will CDSA relate to and work with
existing security standards?
A4: CDSA does not replace any existing standards for data formats or communication
protocols related to security, nor does it establish a new standard in any one security
service area. Instead, it provides a management infrastructure for various security
related services and defines an API through which applications access those services.
Q5: What does it mean to make the PC more
secure?
A5: There are four basic elements of security: privacy, integrity, authenticity, and
non-repudiation.
Privacy: Information is scrambled in such a way
that when viewed it cannot be understood except by the intended reader.
Integrity: Data is transmitted or stored in a
tamperproof manner. If the data is modified, or if forged data is introduced, those
alterations are readily detected.
Authenticity: The identity of the user
responsible for the data creation can be verified.
Non-repudiation : The users that created or sent
the data can not falsely deny that they are responsible for it.
Q6: What problems does CDSA solve?
A6: CDSA makes the process of adding security to software products easier. By writing to
one common API, a software developer can add authentication services (such as smart card
readers), encryption services (such as DES) and the ability to manage security processes
(key recovery, export restrictions, prevention of attacks on the internal software
pieces). Application developers can focus on a single API for all security services, and
not individual API sets for each security offering from multiple toolkit vendors. This
provides application developers with flexibility, consistency, and portability when
implementing security solutions within their products.
Q7: What are the current problems with
security on PCs?
A7: The strength of the PC, a flexible and open architecture, makes it particularly
susceptible to attack from "digital bandits". Although the PC is an optimal
device to access the Internet, it is subject to threat from multiple people 24 hours a
day. Both perception and reality of security risks are preventing people from using the PC
for sensitive transactions, such as e-commerce. Hardware and software developers build
minimal security into their products today. It appears to be more efficient for them to
integrate existing security components from third party developers rather than develop the
technology themselves.
Q8: What is the current status of CDSA?
A8: A reference implementation of V1.2 of CDSA for Windows 95/ NT is available from Intel.
A V2.0 specification has been adopted as a standard by
The Open Group - a standards organization consisting of over 200 member companies that was
formed after the merger of OSF and X/Open. We believe this specification will help the
industry to ensure that application developers can abstract security away for their
applications and have it provided by pluggable security service providers that are
interchangeable.
Q9: Does CDSA compete with existing solutions
from security vendors?
A9: CDSA does not compete with existing solutions on the market today. CDSA does not
directly provide any security services. CDSA is a framework that allows any security
vendor to write add-in modules that will work in the CDSA environment. These add-in
modules would be available to any application that uses the CDSA for its security
capabilities. The CDSA specification provides a set of service provider interfaces (SPIs)
for add-in vendors. If a security vendor writes an add-in module conforming to this SPI,
it will be available to CDSA applications.
Common Security Services Manager
Q10: What is the Common Security Services
Manager (CSSM)?
A10: The Common Security Services Manager is an extensible infrastructure that defines a
certificate-based API for security services, and manages add-in security modules that
provide services to applications, in accordance with the CSSM-defined API.
Q11: How is CDSA different from CSSM?
A11: The CDSA model defines several layers. The Common Security Services Manager (CSSM) is
one layer of the model that provides management of the security infrastructure through a
series of API function calls. The APIs associated with this layer will be consistent
across multiple platforms, providing flexibility to applications requiring security.
Q12: Is the CSSM susceptible to security
attacks?
A12: In order to provide security, CSSM must also protect itself from compromise. CSSM
uses signed manifests as credentials for providing self-checks, and checking add-ins. The
Embedded Integrity Services Library (EISL), and the Integrity Services Library (ISL) are
used to verify and to create these credentials. These libraries provide self integrity
checks, bilateral authentication of modules, and other integrity services.
Q13: Can I run multiple applications
concurrently using CSSM?
A13: Yes. In the current release of CSSM each application will execute its own copy of
CSSM.
Q14: I received a notification that my copy of
the Common Security Services Manager will expire in a few days. Why?
A14: Consistent with other software programs, the expiration date of this software helps
to ensure that participants are using only the most current versions of the software.
Q15: Is a system running with an Intel
PentiumŪ processor required to run the Common Security Services Manager?
A15. We recommend using a system running with an Intel PentiumŪ processor.
Q16: How can I find the current version number
of the CSSM that is running on my system?
A16: Programmatically, the CSSM version number is returned by the function CSSM_GetInfo(
).
Q17: After uninstalling the CSSM, CSSM-related
entries remained in the Windows registry. How can these be removed?
A17: The uninstall process should not leave any residual entries in the Windows registry.
If you observe this problem, please send mail to IAL_Support@intel.com
or call 1-800-628-8686.
CSSM
Add-ins
Q18: What is a Cryptographic Service Provider
(CSP)?
A18: A CSP provides encryption capabilities for the system. CSPs can be either
hardware-based (PC add-in card, smart card, etc.), software-based, or a combination of
both. A CSP typically provides the following functions:
- Data Encryption
- Data Decryption
- Digital Signatures
- Cryptographic Hashing
- Key Generation
- Random Number Generation
- Secure persistent storage of private keys
Q19: Can I use previous cryptographic systems
with CDSA?
A19: In order to support legacy CSPs, vendors can use an adaptation layer that sits
between CSSM and the legacy CSP. This adaptation layer maps the CSSM service provider
interface (SPI) for cryptographic services into the legacy API of the CSP. In the future,
CSP providers will native CSPs which support the CSSM API directly without the need for an
adaptation layer.
Q20: Does Intel provide any CSPs?
A20: Currently, Intel provides one software CSP with its reference implementation of CDSA
V1.2.
Q21: I received a notification that my copy of
the CSP has expired. Why?
A21: Consistent with other software programs, the expiration date of this software helps
to ensure that participants are using only the most current versions of the software.
Q22: Is a system running with an Intel
PentiumŪ processor required to run my copy of the CSP?
A22. We recommend using a system running with an Intel PentiumŪ processor, 90 MHz or
greater.
Q23: What cryptographic algorithms are
supported in this CSP add-in?
A23: The Intel cryptographic add-in security module supports the following cryptographic
algorithms:
- Digital Encryption Standard (DES) - performs bulk
encryption (key length is limited to 40 bits)
- Secure Hash Algorithm (SHA1) - generates one-way
data hashes
- Digital Signature Standard (DSS) - performs
digital signature creation, signature verification, and key-pair generation
- Message Digest (MD5) - generates one-way data
hashes
- Random Number Generator - uses MD5/DES algorithms
Q24: What tools are provided to create a
CDSA-compliant CSP plug-in?
A24: Intel provides a developer toolkit to help CSP add-in vendors move legacy CSPs to the
CDSA environment. This toolkit is called the token adaptation layer (TAL). Intel used the
TAL to develop Intels native software CSP, and two adaptation layers for legacy
CSP-API (RSAs BSAFE and PKCS#11). The TAL provides a framework that vendors can use
to quickly develop CDSA-compliant CSPs.
Q25: What is a Certificate Library?
A25: A certificate library module performs operations on digital certificates. Each
certificate library has knowledge of one or more specific certificate formats. Some of the
operations performed by a certificate library include:
- Creation, registration, and recovery of
certificates from a Certificate Authority
- Signing and signature verification of certificates
- Management of certificate fields
- Export and import of multiple certificate formats
Q26: Does CDSA mandate any certificate formats
for a certificate library?
A26: Certificate format is defined by the add-in vendor module and not by CDSA. A
certificate library vendor can support any format, including X.509, SDSI, or SPKI, for
example.
Q27: Does Intel provide any certificate
libraries?
A27: Intel developed a basic reference implementation of a certificate library supporting
X.509v3 certificates and X.509v2 certificate revocation lists (CRLs). The purpose of the
module is to provide add-in vendors with an example of a complete certificate library.
Portions of this library are Windows* Operating System specific.
Q28: What is a trust policy?
A28: A trust policy is a set of rules used to determine if a requester is trusted or
authorized to perform an action on a data object. Typical actions that might require trust
verification by a trust policy module are:
- Signing of certificates and certificate revocation
lists
- Verifying certificates and certificate revocation
lists
- Revoking certificates
- Some application specific action or operation
Q29: Does Intel provide any trust policy
modules with CDSA?
A29: Intel developed a basic reference implementation of a trust policy module. Trust
policy definition is specific to an application domain. The purpose of the reference
implementation is to provide add-in vendors with an example and starting point for
developing a trust policy add-in module specific to an application domain.
Q30: What is a data service library module
(DLM)?
A30: The data service library module provides persistent storage for security related
objects used throughout the CDSA product. In particular, these objects could be
certificates, certificate revocation lists, public keys, or trust information. A DLM can
use a commercial database package, custom hardware, or native file system as the
underlying mechanism to store these persistent objects. In particular, a DLM provides the
following services:
- Management of data stores, including creation,
deletion, and import/export of data stores
- Storage and management of security objects
- Management of attributes associated with stored
security objects
Q31: Does the DLM store items in a secure
manner?
A31: The definition of the DLM does not require that the stored data be private,
authenticated, or integrity checked. A particular DLM can choose to include any of these
features as part of its service. This has no effect on the APIs for the DLM.
Q32: Does Intel provide a DLM module with
CDSA?
A32: Intel developed a basic reference implementation of a DLM.The purpose of the module
is to provide add-in vendors with an example and starting point for DLM add-in module
development. The reference DLM does not explicitly store data in a secure, or encrypted
format. For any sensitive information, the data should be secured before being stored by
the DLM. Parts of this implementation are Windows* operating system specific.
Q33: Can I create my own trust policy add-in
security module? Or certificate library module? Or data storage library module? Or
cryptographic service module?
A33: Yes. The interface that must be supported by an add-in security module is documented
in a corresponding service provider specification:
Sample Security Applications
Q34: What sample applications are provided by
Intel?
A34: Intel currently provides four sample applications For download : Certificate Manager,
Certificate Viewer, KeyKeeper, and Electronic Shrink Wrapper (ESW). For more information
concerning these application go to the Sample Security Application
page.
Q35: Can I create my own applications using
the CSSM and add-in security modules?
A35: Yes. Using the security APIs documented in the Common
Security Services Manager API Specification you can implement new, secure applications
or augment existing applications with security facilities.
Q36: What is EISL?
A36: The Embedded Integrity Services Library (EISL) is a statically linked library that
can be used within CDSA software modules to provide self integrity checks and bilateral
authentication.
Q37: Why do I need to check for integrity?
A37: Performing integrity checks for CSSM and add-in makes it difficult for an attack to
modify the system without being detected. By providing self check capabilities, each
software module can make sure that its code has not been tampered with, either maliciously
or by accident.
Bilateral authentication ensures that software
modules that use services from each other are authentic and their integrity has not been
compromised. CSSM will check the integrity of add-in modules to ensure that a malicious or
corrupted module is not added to the system. In addition, an add-in module can use EISL to
check the CSSM, to make sure it is not being loaded by a malicious or corrupted CSSM.
Q38: What does ISL provide?
A38: The Integrity Services Library (ISL) is a superset of EISL. In addition to providing
self integrity checks and bilateral authentication, the ISL uses CSSM to sign objects. ISL
also signs and verifies objects other than the software code objects manipulated by EISL.
Examples include objects referenced by URL and arbitrary data streams such as video,
audio, etc.
Q39: What are the differences between EISL and
ISL?
A39: EISL is embedded into the CSSM module, or add-in module, in order to enforce
integrity between modules used within CDSA. EISL uses pre-defined cryptographic hashing
and verification algorithms, as well as certificates and signed manifests, and is not
extensible.
ISL can provide similar services to EISL, but is
allowed to use add-in modules from CDSA in order to manage the certificate, trust, and
cryptographic service routines required to provide integrity. This allows ISL to perform a
broader range of security services.
Q40: What algorithms does EISL use?
A40: EISL uses the following algorithms/formats for module self checks:
- Credentials : X509.V3 certificates for
identification and signed manifests
- Digests : SHA-1
- Signature Algorithm : DSA
- Signature Format : PKCS#7
Q41: What is a signed manifest?
A41: A signed manifest aggregates integrity and authentication information for a list of
digital objects and is signed using public key technology. A manifest is extensible, so
that additional arbitrary attributes can be added to any digital object within the
manifest. Each module that requires a self integrity check, or participates in bilateral
authentication, will provide a signed manifest. CSSM requires that a modules
associated manifest be stored in the file system with the module's executable object code,
where it can be located and verified during bilateral authentication.
Q42: Where can I find out more about EISL/ISL?
A42: The following documents contain more information about integrity services:
- CSSM Embedded Services Integrity Library API
- CDSA Signed Manifest
Q43: What is currently available from
Intel?
A43: Intel provides a demo reference implementation of CDSA V1.2 to qualified individuals.
The reference implementation version of CDSA contains the following:
CSSM/Add-ins:
- Binary to CSSM Core
- Binary to Intel add-ins : Certificate Library
(CL), Data Storage Library (DL), Trust Policy (TP), and weak non-RSA Cryptographic Service
Provide (CSP) modules.
- Binary to Integrity Services Library (ISL) and
Embedded Integrity Services Library (EISL)
- Install Program
- Readme and release notes files
- Sample database (DSA-based for web)
Sample applications:
- Binary to the following CDSA applications:
Certificate Viewer, Certificate Manager, KeyKeeper, ESW
- Source code to Certificate Viewer, Certificate
Manager, and KeyKeyper
- Build environment for the above applications
- Application Notes, ESW Notes
To find out more about qualifying for the demo
reference implementation, send email to cdsa@ibeam.intel.com. Include
your name, company name, mailing address and phone number. The demo software is available only in the United States
and Canada.
Q44: When will the Common Security Services
Manager version 1.2 expire? When will the next version be available?
A44: The Common Security Services Manager version 1.2 expires on Sunday, September
30, 1998. To continue using the CSSM you must download a new copy from Intels
corporate web site. A date for the next version of CSSM has not been determined.
Q45: Is special hardware required to run the
Common Security Services Manager, or any of the related downloadable software?
A45: Special hardware is NOT required to run the Common Security Services Manager, the
Cryptographic Token, or the sample security applications. For best performance, we
recommend a system with an Intel PentiumŪ processor (90 MHz or greater). The system
should have a minimum 8 MB of RAM; 16 MB is recommended.
Q46: Does the Common Security Services Manager
require any other special software or system configuration?
A46: The requirements for the CDSA reference implementation are as follows:
- Operating System
- Windows* 95, Windows NT* 4.0
- Database
- To run the sample applications, you will need ODBC
drivers for Microsoft Access* 7.0, (version 3.50.00.00 or greater).
-
Q47: What database does the Intel reference
implementation use for local certificate storage?
A47: The Intel reference implementation uses ODBC drivers for Microsoft Access* 7.0.
Support for other databases would have to be provided by other Data Storage Library
add-ins.
Q48: When will the Common Security Services
Manager run on other operating systems, such as Windows 3.1 and UNIX*?
A48: The CSSM API specification is intended to be platform independent. A source and
release date for a CSSM reference implementation on other platforms has not been
determined.
Q49: What release notes are available and how
do I obtain them?
A49: Release notes for the Intel CSSM and Intel Add-ins are in a document titled relnotes.doc, and the readme file
for the software download is included in the document titled readme.txt.
Please send general comments and questions to cdsa@ibeam.intel.com
* Legal Information © 1998 Intel Corporation
|