付録 1. 今後の動向の調査方法 (英文)
Appendix A. How to judge the future trend of API This material is based on a method that I have been using to organize different topics for the I-4 (International Information Integrity institute). I have modified the criteria used to judge the maturity level so that they are more specific to the APIS this report is studying. This organization is based on the idea that technology and ideas progress through several different stages. I have narrowed it to the following five stages:
Stage Definitions Idea Future or new concept with no physical representation or practical implementation Interest comes from potential relevance Proof of Concept Small-scale implementation or laboratory experiment whose results show potential for viable applications Interest based on early positive results Growth Period of rapid marketplace acceptance Interest based on inevitability, and need to manage growth Maturity Ubiquitous acceptance and usage Interest comes from management and maintenance Decline Topic area and usage decline in importance toward obsolescence Interest in decommission or migration to replacement
These can be shown on a graph as below:
196 Most ideas start with an initial acceptance, then some skepticism that is followed by a lot of marketing and selling. After that there is a decrease in importance as a process of working out the bugs takes place. Then, for things that will really get accepted there is a slow increase during the proof of concept and growth stage. After that importance levels off and then begins to decline. For I-4 we treat subjects differently, depending on their stage. For example we might to an exploratory paper for something early in the life cycle; but look at replacement strategies for a technology in the maintenance phase. Below are the criteria that I mentioned that we use to judge the phase.
197
付録 2. セキュリティ関連 API の標準化動向 (英文)
Appendix B. Standardization Trends This section discusses the standardization process of the different APIs studied. Fro each API there will be a description of where it originated and its progress towards becoming a standard. These APIs are in various stages with some not yet completed standards while others have been standards for quite a while and are undergoing revisions.
A2.1 APKI – (Architecture for a Public Key Infrastructure) The APKI standard was created by the members of the Open Group. The APKI (Architecture for a Public Key Infrastructure) is a high level architecture that specifies both APIs and protocols. Although not an API itself, it organizes these APIs and protocols into logical layers. The goal of the APKI was to bring order into the PKI world in the early days of PKI. Each layer in the APKI describes specific services. Where appropriate standards existed they were adopted into the APKI. The missing protocols or APIs in the structure were filled by creating new APIs or protocols.
The standardization process consisted of coming to agreement on what should be in each layer and what standards should be referenced or created to occupy the layers. Where standards did not specify enough information to guarantee interoperability, the APKI included profiles or specific subsets of the standards.
The APKI APIs and protocols were required to support the establishment of domains of trust and governance, confidentiality, integrity, authentication and non-repudiation. Monitoring and auditing of PKI services would need to be supported.
The APKI layers are shown below:
Applications
System Security Secure Protocols Security Policy Enabling Services Services (authorization) Protocol Security Services (Identification, authentication) Supporting Services Long Term Key Services (audit, directory, time)
Cryptographic Services
Cryptographic Primitives
198
Work began on the APKI in 1994. Many of the necessary APIs and protocols were either in draft or missing. The APKI was finished and released in March of 1999. Its Open Group document number is G801 and its ISBN is 1-85912-221-3. An HTML version is available at: http://www.opengroup.org/pubs/catalog/g801.htm .
The released standard fills in the APKI layers as shown below:
Applications
System Secure Protocols SecuritSecurityy PolicyPolicy Security IETF IPSec, IKE Services Enabling Interfaces: Each secure protocol typically has its ((authorizationauthorizationauthorization)) Services own interface Protocols: Defines in (identity, privilege attribute Protocol Security Services authen.) standards by ANSI Protocols: Multiple protocols will continue to be X9, OSF DCE, needed SESAME and OMG APIs: Session oriented – IETF GSS-API, Store CORBASEC and forward and Non-Repudiation– IETF IDUP-GSS-API Profiles: Need to be developed Supporting ServServicesices Negotiation: IETF GSS-API described in RFC Protocols 2478 IETF SNTP (time) Long Term Key Services APIs: Open Group Protocols: IETF PKIX family XDAS (distributed APIs: CSSM/CDSA Audit) Profiles: IETF PKIX (RFC 2459, 2527) LDAP API (directory) Profiles: Open Group Cryptographic Services and IETF LDAP APIs: CDSA/CSSM APIs profiles Profiles: Need to be developed for specific PKI environments (CORBA, DCE, Financial, etc.)
Cryptographic Primitives APIs: CSSM and other crypto algorithms (RSA, DH, DES, AES, etc.) Profiles: Still Needed
Not all of the desired functionality has been implemented. In particular the System Security Enabling Services section is empty. This is partly because there are so many different methods of doing this that there is no clear choice for a standard. These services are usually embedded in the operating system or sometimes in applications.
Current standards work on the APKI has stopped with the formal publication of the standard in March of 1999. The Open Group has no immediate plans to create a revision to the APKI, although some individual members of the Open Group have enlarged it for their own purposes. An outgrowth of the APKI led to the current Open Group work on security patterns.
199
Title Architecture for Public-Key Infrastructure Publication ISBN 1-85912-221-3, Open Group Document G801 Information Date Published March 1999 Revision History No Revisions Controlling The Open Group, www.opengroup.org Organization Authors Anne Anderson, Hewlett-Packard Company Charles Blauner, JP Morgan & Co. Inc. Belinda Fairthorne, Fujitsu-ICL Warwick Ford Robert Jueneman, Novell, Inc. Ellen McDermott, Open Market Howard Melman, formerly OSF Denis Pinkas, Groupe Bull Walt Tuvell, formerly OSF John Wray, Compaq Computer Corporation Ordering http://www.opengroup.org/pubs/catalog/g801.htm Information
A2.2 PKCS#11 (Public-Key Cryptography Standard) PKCS#11 is one of a sequence of standards created and controlled by RSA Security. Although not a standards body, RSA Security has invited participation from outside in the creation and modification of their family of PKCS (Public-Key Cryptography Standards) standards.
PKCS#11, also called Cryptoki (short for Cryptographic Token Interface), defines an architecture and specifies the interfaces used for storing cryptographic keys or certificates in hardware devices or tokens such as smart cards. In addition to smart cards, PKCS#11 was designed to work with other types of hardware such as disks and PCMCIA cards. PKCS#11 was designed to be both application and operating system independent. It provides a low level programming interface that hides these hardware differences from the application developer. Applications that use this API do not need to know what kind of hardware device they are talking to.
PKCS#11 was announced by RSA Security on 12 Jan 1994 in conjunction with an announcement by National Semiconductor about their iPower series of smart cards. Version 1.0 of the completed standard was released a little over a year later on the 28th of April, 1995. It and all subsequent versions are available on RSA Security’s web site at: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html .
Version 1 of PKCS#11 was quite successful and was the first standard of its type. Its usage showed where improvements were needed. These improvements led to a major revision about two years later. Whereas version 1 was 132 pages, version 2 was over twice as long. Two drafts of version 2 were released in 1997, version 2 draft 1 on 15 April 1997 and draft 2 on 1 July 1997. Neither of these drafts
200 was released as a finished standard and they are not officially supported. Finally, a finished PKCS#11 version 2.01 was released on 22 December 1997.
Version 2.01 added additional functionality, support for the C++ programming language and support for many algorithms that were new or not included in version 1.
Version 2.10 was released in December of 1999. The current version of PKCS#11 is 2.11 that were completed in late 2001. Version 2.11 supports additional algorithms. The table below shows a comparison of the algorithms and functions supported in versions 1, 2.01 and 2.11.
PKCS #11v1 PKCS #11v2.01 PKCS #11v2.11 Public/Private RSA, DSA, DH RSA, DSA, ECDSA, RSA, DSA, ECDSA, Key Algorithms DH, KEA DH, X9.42, KEA Secret Key RC2, RC4, DES, RC2, RC4, RC5, DES, RC2, RC4, RC5, AES, Algorithms DES2, DES3 DES2, DES3, CAST, DES, DES2, DES3, CAST3, CAST128, CAST, CAST3, IDEA, CDMF, CAST128, IDEA, SKIPJACK, BATON, CDMF, SKIPJACK, JUNIPER BATON, JUNIPER Hash Functions MD2, MD5, SHA-1 MD2, MD5, SHA-1, MD2, MD5, SHA-1, FASTHASH FASTHASH
Note the addition in version 2.01 of KEA and SKIPJACK that were part of the U.S. government’s collection of key escrow algorithms. Important additions in version 2.11 are support for ANSI X9.42 and the AES or Advanced Encryption Standard. Version 2.11 is now 373 pages and includes additional functionality as well as support for a larger number of standard algorithms. In August of 2001 the first amendment to version 2.11 was proposed. This amendment proposes support for additional devices called Personal Trust Devices (PTD). It defines a PTD as a device that is carried, controlled and used by a single user most of the time and is capable of advanced security. The device must also support user input in order to authenticate the user. Examples of such devices include PDAs and mobile phones.
It should be noted that not all implementers of PKCS#11 implement the entire specification. Using the specification as a framework they tend to implement support just for the features that are included in either their hardware or software. Similarly they tend to support only a subset of the algorithms included in the specification.
Title PKCS #11: Cryptographic Token Interface Standard Publication Information DaDatete Published 28 April 1995 Revision History Version 2.01, Dec 1987 Version 2.10, Dec 1999 Version 2.11, June 2001 Controlling RSA Security Organization
201 Authors Richard Ankney, Fischer International Ashar Aziz, Sun Microsystems Inc. Ali Bahreman, Bellcore Frank Balluffi, Bankers Trust Sara Bitan, RadGaurd LTD. Eric Blossom, COMSEC Partners John C. Brainard, Security Dynamics Liudvikas Bukys, University of Rochester Steve Burnett, RSA Data Security, Inc. Victor Chang, RSA Data Security, Inc. Bruno Couillard, EMCON Ltd. Greg Dunn, Telequip Corp. Steve Dussé, RSA Data Security, Inc. Alan Eldridge, IRIS Associates Mark H. Etzel, AT&T Bell Laboratories Bill Fox, National Semiconductor Hazem Hassan, Datakey, Inc. Thomas C. Jones, ViaCrypt John Kennedy, Cylink Larry Kilgallen, LJK Software Kevin Kingdon, Novell Scott Lindsay, Mobius Roland Lockhart, BNR Hoa Ly, RSA Data Security, Inc. Thi Nguyen, Secure Communications Inc. Denis Pinkas, Bull Jim Press, ICL P. Rajaram, Bellcore William Rohland, Datakey, Inc. Andrew Ryan, SmartDiskette Limited Paul Schlyter, AU System Wolfgang Schneider, GMD Stephen Seal, CRYPTOCard Don Stephenson, Sun Microsystems, Inc. Bruno Struif, GMD Mandan M. Valluri, National Semiconductor Charlie Watt, SecureWare David E. Wood, DataKey, Inc. Richard R.D. Young, BNR Arthur Zachai, representing Telequip Corp. Neal Ziring, NSA Ordering http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html Information
202
A2.3 GCS-API (Generic Cryptographic Services API) The GCS-API was released as an X/Open preliminary specification by the X/Open (now the Open Group) in June of 1996. Its Open Group document number is P442 and its ISBN is 1-85912-195-0. It is available only in hard copy from the Open Group at http://www.opengroup.org/publications/catalog/p442.htm .
The standard is structured in three sections. The first section specifies basic cryptographic functions. The second section describes advanced functions, including key management. The final section consists of a series of appendices. These appendices include example implementations of the specification. All functions are described and specified using the C programming language syntax.
The GCS-API standard was produced under the direction of X/Open by the Security Working Group. The members involved consisted of several large systems vendors, several security companies and several government agencies. The CGS-API preliminary specification includes a conformance statement (Chapter 12) that specifies the minimum requirements for implementing the specification.
The GCS-API benefited from the use of the X/Open Distributed Security Framework and NIST’s proposed FIPS-Cryptographic Service Calls specification. IBM Corporation and the ANSI X9F1 committee also made significant contributions.
As part of the MISPC program the U. S. NIST produced a reference implementation of the GCS-API. See http://csrc.nist.gov/pki/mispc/refimp/referenc.htm.
Title Generic Cryptographic Services API Publication ISBN 1-85912-195-0, Open Group Document P442 Information Date Published June 1996 RRevisionevision History No Revisions Controlling The Open Group, www.opengroup.org Organization Authors BULL, S.A. Hewlett Packard International Business Machines Corporation (IBM) International Computers Limited (ICL) USA National Institute of Standards and Technology (NIST) USA National Security Agency (NSA) Olivetti Systems and Networks s.r.l OpenVision Siemens Nixdorf Trusted Information Systems, Inc Fischer International RSA Data Security, Inc Ordering http://www.opengroup.org/publications/catalog/p442.htm Information
203
A2.4 CDSA 2.0 (Common Data Security Architecture) The CDSA 2.0 standard was released as a technical standard by the Open Group with the title: Common Security: CDSA and CSSM, Version 2 in November of 1999. It is published with Open Group document number C902, ISBN 1-85912-236-1. CDSA represents the evolution and combination of several cryptographic and key and certificate management APIs. This work was done by members of the PKI Task Group, a subset of the Security Program Group of the Open Group.
Almost as soon as the GCS-API was finished there arose a need for a standard API that support key and certificate management as well as cryptographic services. This effort began independently in the Open Group and also with Intel Corporation. Intel had cooperated with Microsoft in the creation of the first version of the Microsoft Crypto API (MS-CAPI) and wanted to extend MS-CAPI with additional functionality.
Note receiving much cooperation from Microsoft, Intel began developing an independent cryptographic API which they termed the Common Data Security Architecture or CDSA. The first version that was widely used was CDSA 1.2.
During this same time period the Open Group was evaluating several APIs with idea of combining the best features of each one into a single API. These APIs included Nortel’s CMS-API and the NSA’s CM API. Over the summer of 1997 these two APIs were merged into an interim API. This API was later combined with CDSA 1.2 to create CDSA 2.0. Other significant contributors to CDSA 2.0 include IBM, TIS, Netscape, Hitachi, Hewlett Packard, Motorola, NIST and Apple.
The evolution of CDSA looks something like this:
Nortel CMS-API
Interim CM API
NSA CM API Open Group CDSA 2.0, 2.3
Intel CDSA 1.2
Other Technical contributors: Apple, IBM, TIS, Netscape, Hitachi, HP, Motorola, and NIST
Apple Computer contributed significantly to the final stages of the development of CDSA by incorporating it into their Mac X operating system. During this process they found errors which were fixed. As a result of corrections from Apple, IBM and others a list of corrigenda or corrections was
204 released. This was incorporated into the standard in May of 2000 and it was released as CDSA 2.3. In addition, the specification was reorganized to avoid duplication and make it easier to use. A new document number (C914) and ISBN (1-85912-202-7) were assigned.
Title Common Security: CDSA and CSSM, Version 2.3 Publication ISBN 1-85912-202-7, Open Group Document C914 Information Date Published May 2000 Revision History Common Security: CDSA and CSSM, Version 2, Nov 1999, ISBN 1-85912-236-1, Open Group Document C902 Common Security: CDSA and CSSM, Version 2.3, May 2000, Open Group Document C914, ISBN 1-85912-202-7 Controlling The Open Group, www.opengroup.org Organization Authors Intel Architecture Labs, Intel Corporation Apple Computer Corporation IBM Corporation (IBM) Entrust Hewlett-Packard Motorola Netscape Sun Microsystems Trusted Information Systems, Inc. Ordering http://www.opengroup.org/publications/catalog/c914.htm Information
In May of 2000, Intel also launched an open source reference implementation. This is available at: http://developer.intel.com/ial/security/index.htm . Intel also provides source for a CDSA conformance test suite. Intel produced this reference implementation for the Microsoft Windows and Linux environments. Other companies that have licensed Intel’s CDSA reference platform have produced versions for the following environments:
Organization CDSA Usage Apple Mac OS Bull Linux Compaq UNIX Hewlett-Packard HP-UX IBM Corporation OS/390, OS/400, AIX Cylink PKI Toolkit Motorola PKI Toolkit Baltimore Technologies PKI Toolkit
In addition, Bull, Caldera and Intel have created a 64 bit optimized Linux version for use on the Intel Itanium processors. This version is aimed at the large server market.
205 IBM has used CDSA in their extensive KeyWorks security solution. KeyWorks combine with IBM’s PKIX implementation is implemented along the guidelines specified in the APKI.
A2.5 CDSA/HRS (Common Data Security Architecture/Human Recognition Services) HRS was created to cryptographically protect biometric data. HRS was originally called User Authentication Services (UAS) and was developed beginning in 1998. It was designed to be a plugin module to the CDSA framework, using the CSSM (Common Security Services Manager) EMM (Elective Module Manager). HRS was developed in parallel with a stand-alone version that supports the BioAPI.
The HRS is designed to be used by application developers and biometric technology developers. When combined with CDSA it provides an identification and authentication service.
John Wilson from Intel Corporation was the technical editor for both the Open Group’s HRS API and the BioAPI Consortium’s version. He was able to keep them consistent. Version 2.0 of HRS was formally released as an Open Group Technical Standard in June of 2001.
HRS v2 is based on previous work done by the BioAPI Consortium that was released as version 1.0.8 on 20 March 2000.
Title CDSA/CSSM Authentication: Human Recognition Service (HRS) API, Version 2 Publication Open Group Document C013 Information Date Published June 2001 Revision History No Revisions Controlling The Open Group, www.opengroup.org Organization Authors John Wilson, Intel Members of the BioAPI Consortium (see list under BioAPI) Ordering http://www.opengroup.org/publications/catalog/c013.htm Information
More information can be found in this document under the description of the BioAPI released by the BioAPI Consortium.
A2.6 BioAPI The BioAPI Consortium was founded in 1998 to create an API for biometric data. In 1999 the BioAPI Consortium merged efforts with the BAPI (Biometric API) Working Group that was working on a similar API called HA-API (Human Authentication API). The HA-API was originally developed under contract to the U. S. government. The U. S. NIST played an active role in the development of this API. The result of the merger was a combination of the best parts of the two APIs under the BioAPI name.
206
At the same time the BioAPI Consortium was reorganized to include members from the BAPI Working Group.
Around this same time period the Open Group began working with the BioAPI Consortium to develop what would become the HRS API. The HRS API is now incorporated as part of the BioAPI.
Parts of the BioAPI are derived from the following APIs: • HA-API version 2.0, 22 April 1998 • HA-API version 2.02 extensions, 17 February 1999 • Draft BIOAPI Reference Manual, 25 February 1999 • BAPI SDK Version 1.1 High Level API – Level 3, 1 June 1998 • Draft BioAPI/UAS Specification 1.0 Version 1.2 Release, April 1999
The specification is similar to the Open Group HRS specification described above. BioAPI calls are preceded by BioAPI while similar HRS calls are preceded by CSSM_HRS.
Title BioAPI Specification Version 1.1 Publication Information Date Published 16 March 2001 Revision History BioAPI Specification Version 1.0, 30 March 2000 BioAPI Specification Version 1.1, 16 March 2001 Controlling The BioAPI Consortium Organization Authors SAFLINK Corporation, Cathy Tilton, Chair Unisys Corporation, Fred Herr, Secretary Intel, John Wilson, Technical Editor Compaq Computer Corp., Manny Novoa Iridian Technologies, James Cambier Treasurer NIST, Fernando Podio Mytec Technologies, Inc., Colin Soutar Ordering http://www.bioapi.com/BioAPI_home.htm Information
The BioAPI represents the combined work of several organizations and is the only standard API for biometric data available today.
A2.7 GSS-API (General Security Service API) The GSS-API was published along with the Internet Engineering Task Force, commonly known as the IETF. The IETF along with its sibling organization the IRTF (Internet Research Task Force) are governed by the Internet Architecture Board (IAB) that is chartered by the Internet Society (ISOC). The IETF is organized into eight areas.
207 When a need arises for a new standard, a working group (WG) is chartered in the appropriate area. Working groups are considered to be temporary, when their work is finished they are dissolved. The complexity of the task determines the life of a working group. Some working groups have been around for ten years, others may come and go in two years. Working groups publish their results as Request For Comments (RFC) documents. These progress from a series of drafts documents, get assigned a draft RFC number and are finally released as an RFC. A working group typically starts as a Birds of a Feather (BoF) session during one of the thrice-yearly IETF meetings. Most of the actual writing and other working group activity take place off line via e-mail lists. The IETF meetings are reserved for discussion, informal surveys and informative presentations.
Most work done by the IETF is in the creation of Internet protocols. APIs are an exception and are created when a need arises. Most, but not all, of the security related standards produced by the IETF are down in the Security Area. The GSS-API was produced by members of the Common Authentication Technology (CAT) Working Group. The CAT Working Group is one of the oldest IETF working groups. The primary goal of this working group is to produce the specifications for interoperable distributed security services. These services include authentication, integrity and confidentiality.
The first version of the GSS-API, authored by John Linn was complete in September of 1993. Version 2, also by John Linn, was completed in January of 1997. Version 2 is an incremental update to version 1. It was based on changes needed from experiences with implementing version 1. The page count of version 2 nearly doubled from about 50 pages in version 1 to nearly 90 in version 2. The current version, described in RFC 2743 and also written by John Linn was released in January of 2000. This version is called GSS-API Version 2, Update 1 and it is just over 100 pages. It also only makes minor, incremental changes to the previous version.
Title Generic Security Service Application Program Interface Publication Information Date Published January 2000 Revision History GSS-API, RFC 1508, September 1993, John Linn GSS-API v2, RFC 2078, January 1997, John Linn GSS-API v2 update 1, RFC 2743, January 2000, John Linn Controlling The Internet Engineering Task Force, www.ietf.org Organization Authors John Linn Ordering http://ietf.org/rfc/rfc2743.txt Information
In addition to releasing two revisions to the GSS-API, the CAT Working Group has also released a number of related RFCs. New drafts in the CAT WG and other IETF working groups continue to reference and depend on the GSS-API.
Since the GSS-API is independent of the specific security mechanisms that it calls, several lower level specifications have been released that describe how to use different specific mechanisms with the GSS-API. The GSS-API is also programming language independent and RFCs have been released that describe the different language bindings for the GSS-API.
208
RFC 1964, written by John Linn and released in June of 1996, describes how to implement the GSS-API using Kerberos version 5 technology. Most of the RFC describes Kerberos token and name formats that are to be used when implementing the GSS-API.
RFC 2025, written by Carlisle Adams and released in October of 1996, describes the convention and procedures that must be followed to implement the GSS-API using the Simple Public-Key Mechanism (SPKM). The SPKM data formats that are specified were designed to be as similar to the Kerberos ones as possible to make implementation easier.
RFC 2478, written by E. Baize and Denis Pinkas and released on December of 1998, describes a security negotiation mechanism for the GSS-API. This mechanism, called the Simple and Protected GSS-API Negotiation Mechanism, allows different GSS-API implementations that use multiple security mechanisms to negotiate with each other until they agree on a common mechanism to use.
C Language bindings for the GSS-API are described in RFC 2744 and Java Language bindings are described in RFC 2853.
A draft that uses the GSS-API with Simple Authentication and Security Layer (SASL) is currently in progress in the CAT Working Group.
A2.8 IDUP-GSS-API (Individual Data Unit Protection – Generic Security Service API) The IDUP-GSS-API extends the GSS-API to provide protection for data. The GSS-API is oriented towards protecting session information while the IDUP-GSS-API applies the protection to individual data units such as files or e-mail messages. The protection includes data origin authentication, data integrity protection and data confidentiality protection.
The IDUP-GSS-API was produced by the CAT Working Group of the IETF. As described in the section on the GSS-API, the CAT Working Group is part of the Security Area in the IETF. The specification is described in RFC 2479, which was released in December of 1998. There have been no revisions to the IDUP-GSS-API since its release and there are no current drafts in work to replace it.
Like the GSS-API, the IDUP-GSS-API is mechanism independent in that it describes a set of security services at a generic level that may be implemented by different security mechanisms. These may include public or secret key systems. The IDUP-GSS-API is also protocol independent and may be used in a broad range of environments
The IDUP-GSS-API references the GSS-API and relies on it for describing credentials, tokens, naming and security mechanism types. It differs mostly in the environment in that the IDUP-GSS-API ties the protection provided to the individual data units whereas the GSS-API ties it to the session or security association between two endpoints.
Title Independent Data Unit Protection Generic Security Service Application Program Interface
209 Publication Information Date Published December 1998 Revision History No Revisions Controlling The Internet Engineering Task Force, www.ietf.org OrganOrganizationization Authors Carlisle Adams, Entrust Technologies Ordering http://ietf.org/rfc/rfc2479.txt Information
The IDUP-GSS-API was released as an informational RFC, instead of a standard RFC.
A2.9 XGSS-API (Extended GSS-API) The current version of the XGSS-API or Extended GSS-API is based on an Internet draft written by Denis Pinkas and Tom Parker in 1998. The first version was published in November of 1995. The draft extends the GSS-API by adding two additional functions.
The first function is support for multiple security attributes. The XGSS draft specifies how to construct authorizations based on different types of security attributes.
The second additional function is the finer control of delegation by allowing the specification of the delegation method, which can accept the security context and allowing for other restrictions on delegation.
The XGSS draft was submitted to the CAT Working Group of the IETF in 1998. IETF drafts automatically expire after six months if they are not adopted as RFCs or if there are not additional revised forms of the drafts released. The XGSS draft expired on 9 May 1999. Expired drafts are not kept on the IETF web site, but a copy of Version 3 (the last version) of the XGSS-API draft can currently be found at: http://globecom.net/ietf/draft/draft-ietf-cat-xgssapi-acc-cntrl-03.html .
There is also some relationship and some overlap between the functions provided in the XGSS-API draft and the GAA-API and aznAPIs that are described below. A comparison between the XGSS-API and GAA-API in 1998 determined that they were complementary.
Nephilim, a Java based SESAME implementation produced at the University of Illinois at Urbana-Champaign and funded by the U. S. National Security Agency, uses both the GSS-API and XGSS-API extensions to implement the SESAME security mechanisms.
There have been four versions of this draft, the most recent being Version 3, released in November of 1998. There have been very few, if any, changes between the different drafts. The reason that new drafts have been released is to bring them to the attention of the CAT Working Group in the IETF to encourage further discussion.
210 Title Extended Generic Security Service APIs: XGSS-APIs Access Control and Delegation Extensions Publication Information Date Published XGSS-API Version 0, 21 November 1995 XGSS-API Version 1, 5 July 1996 XGSS-API, Version 3, 9 November 1998 Revision History XGSS-API V3 9 November 1998 Controlling The Internet Engineering Task Force, www.ietf.org Organization Authors Tom Parker and Denis Pinkas Ordering http://globecom.net/ietf/draft/draft-ietf-cat-xgssapi-acc-cntrl-03.html Information
A2.10 GAA-API (Generic Authorization and Access Control) API The GAA-API is designed to facilitate authorization decisions by applications. An application would use the GAA-API functions to determine if a requested action is authorized and also to request additional access control information about a specific resource.
The work done to create the GAA-API was initiated by the Information Sciences Institute of the University of Southern California as part of the Global Operating Systems Technology (GOST) Group. This work has led to the creation of two Internet drafts that have been submitted to the CAT Working Group at the IETF. There have, to date, been six versions of each draft. The main draft describes the access control framework, the other draft specifies the C Language bindings for implementing the GAA-API.
The University of Southern California maintains a web page for the GAA-API project at: http://www.isi.edu/gost/info/gaaapi/gaa_api.html. In addition to writing the draft specifications, they are also making reference implementations of the API available. The current version is GAA-API v0.6.2.
The GAA-API like the XGSS-API was never released as a set of finished RFCs. Also like the XGSS-API, the GAA-API has been referenced and used in different projects and papers.
Title Generic Authorization and Access Control API (GAA-API) Publication Information Date Published 22 November 2000
211 Revision History draft-ietf-cat-acc-cntrl-frmw-00.txt, August 07, 1998 draft-ietf-cat-acc-cntrl-frmw-01.txt, November 17, 1998 draft-ietf-cat-acc-cntrl-frmw-02.txt, June 23, 1999 draft-ietf-cat-acc-cntrl-frmw-03.txt, March 9, 2000 draft-ietf-cat-acc-cntrl-frmw-04.txt, July 11, 2000 draft-ietf-cat-acc-cntrl-frmw-05.txt, November 22, 2000 draft-ietf-cat-gaa-cbind-00.txt, August 07, 1998 draft-ietf-cat-gaa-cbind-01.txt, November 17, 1998 draft-ietf-cat-gaa-cbind-02.txt, June 24, 1999 draft-ietf-cat-gaa-cbind-03.txt, March 9, 2000 draft-ietf-cat-gaa-cbind-04.txt, July 11, 2000 draft-ietf-cat-gaa-cbind-05.txt, November 22, 2000 Controlling The Internet Engineering Task Force, www.ietf.org Organization Authors Tatyana Ryutov and Clifford Neuman Ordering http://www.isi.edu/gost/info/gaaapi/doc/doc.html Information
A2.11 aznAPI (Advanced Authorization API) The Authorization (AZN) API was published by the Open Group in January of 2000 as an Open Group Technical Standard. Authorization work began at the Open Group in late 1997. Several of the Open Group’s Security Program Group had been involved with other authorization initiatives, notably the Distributed Computing Environment (DCE) and Common Object Request Broker Architecture (CORBA) security and authorization models.
In parallel with the development of the aznAPI, DASCOM was developing an authorization product. This proved valuable because features of the API could be tested and the API adjusted where it needed to be. DASCOM Corporation was later absorbed into the Tivoli division of IBM.
The members of the Open Group that developed the aznAPI were also able to take advantage of the XGSS-API and GAA-API work that was being done in the IETF.
The goal of the aznAPI was to define a simple interface that both security component providers could use to invoke authorization functionality and applications developers could use for building security aware applications. It is also designed to allow central management of the authorization services. The aznAPI follows the ISO authorization model described in ISO/IEC 10181-3.
Title Authorization (AZN) API, usually referred to as the aznAPI Publication ISBN 1-85912-266-3, Open Group Document Number C908 Information Date Published January 2000 Revision History Controlling The Open Group, www.opengroup.org Organization
212 Authors Bob Blakley, DASCOM Warwick Burrows, DASCOM Greg Clark, DASCOM Adam Murdoch, DASCOM Frank Siebenlist, DASCOM Additional input and review by representatives from Hewlett-Packard Company IBM Corporation Sun Microsystems Inc. Entrust Technologies Baltimore Technologies Ordering http://www.opengroup.org/publications/catalog/c908.htm Information
There are currently no revisions of corrections to the aznAPI specification.
A2.12 General Note on the Open Group Structure and Organization
The Open Group is a merger of several different standards organizations. Its primary goal is interoperability between different computing environments. It began with the combining of the Open Software Foundation and X/Open that merged in the spring of 1996. Since then the Directory Interoperability Forum and the Electronic Messaging Association have also become part of the Open Group.
Open Software Foundation
1996 1998 2000
X/OPEN
Directory Interoperability Forum
Electronic Messaging Association
213
In the early days of the Open Group, it was divided into separate program groups. These program groups would create internal task groups that worked on a specific project. Often task groups made up of representatives from the user community created requirements documents and task groups from the vendor community created APIs, reference code and other specifications. Some specifications, such as the APKI, were joint efforts.
Today the Open Group is divided into separate Forums that are focused on a specific area of technology. The current Open Group Forums are Active Loss Prevention, Architecture, Directory Interoperability, EMA (Electronic Messaging), Enterprise Management, Mobile Management, Platform, Quality of Service, Real Time & Embedded Systems and Security.
The Open Group organizes quarterly conferences for its forums to meet in. The first two days are usually open to the general public and have a theme relating to one of the forums. Forums and smaller task groups often communicate between meetings by telephone or e-mail.
Open Group members usually come from large international corporations and consist of both vendor and customer members. The Open Group provides an environment where customers and vendors can create solutions together. When a document is ready for approval a voting process takes place. Each member company is entitles to one vote.
In addition to the forum activity, the Open Group also has a testing and certification program. The Open Group also provides meeting and membership services to other organizations.
A2.13 General Note on the IETF Structure and Organization
The Internet Engineering Task Force (IETF) is part of the Internet Society. The Internet Society (ISOC) currently consists of more than 6000 members and 150 corporate members among 170 countries. The ISOC administers Internet address through the Internet Assigned Numbers Authority (IANA), conducts research into future Internet protocols via the Internet Research Task Force (IRTF) and designs Internet protocols via the IETF. The IETF along with its sibling organization the IRTF are governed by the Internet Architecture Board (IAB), which is chartered by the Internet Society (ISOC). The IAB communicates with the IETF via the Internet Engineering Steering Group (IESG) and with the IRTF via the Internet Research Steering Group (IRSG).
214
Internet Society ISOC
Internet Assigned Internet Architecture Numbers Authority Board IANA IAB
Internet Engineering Internet Research Task Force Task Force IETF IRTF
The IETF is organized into eight areas, each presided over by one or two Area Directors who are appointed by the IAB. The IESG membership consists of the Area Directors and a Chair, also appointed by the IAB. The eight areas are Applications, Internet, Operations and Management, Routing, Security, Sub IP, Transport and User Services.
Internet Engineering Task Force (IETF)
Internet Engineering Steering Group (IESG)
Applications Area Security Area
Internet Area Sub IP Area
Operations and Transport Area Management Area
Routing Area User Services Area
215
When a need arises for a new standard, a working group (WG) is chartered in the appropriate area. Working groups are considered to be temporary; when their work is finished they are dissolved. The complexity of the task determines the life of a working group. Some working groups have been around for ten years, others may come and go in two years. Working groups publish their results as Request For Comments (RFC) documents. These progress from a series of drafts documents, get assigned a draft RFC number and are finally released as an RFC. A working group typically starts as a Birds of a Feather (BoF) session during one of the thrice-yearly IETF meetings. Most of the actual writing and other working group activity take place off line via e-mail lists. The IETF meetings are reserved for discussion, informal surveys and informative presentations.
Most work done by the IETF is in the creation of Internet protocols. APIs are an exception and are created when a need arises. Architecture designs are also produced by some of the working groups. Most, but not all, of the security related standards produced by the IETF are down in the Security Area. Currently there are security related drafts and RFCs being prepared in five of the other Areas as well as in the IRTF. All of the APIs done by the IETF that are discussed in this report were done as part of the work of the Common Authentication Technology (CAT) Working Group. The Authentication, Authorization and Accounting Working Group have moved from area to area and currently reside in the Operations and Management Area.
Internet drafts become RFCs when they are submitted to the IAB and the RFC editor. Standards track RFCs require the existence of two independent fully interoperable implementations before the RFC will be issued.
The IETF occasionally partners with other organizations to develop standards. A recent partnership with the World Wide Web Consortium (W3C) was used to develop the XML Digital Signature standard.
216
付録 3. セキュリティ関連 API の今後の動向 (英文)
Appendix C. Acceptance and Future Prospects This section of the report assesses each APIs current level of acceptance and describes its future prospects. The chart below is an aid to judging the maturity of technology. These categories will be used as an aid to estimating the maturity of an API. A box that indicates the current state for each characteristic will be shaded.
Idea Proof of Growth Maturity Decline Concept Market None 1%-5% 5%-30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
A3.1 APKI – (Architecture for a Public Key Infrastructure) The APKI is different from the other standards discussed in this document because it is a high level PKI architecture. It success or failure is more difficult to judge because it will not show up in products.
The APKI had contributions from many large, international system vendors (Compaq, Digital Equipment Corporation, Fujitsu-ICL, Groupe Bull, Hewlett-Packard, IBM, Novell, Siemens and Sun Microsystems, etc.) from many large customers (Boeing, Citicorp, JP Morgan, Lockheed-Martin, Shell International, etc.) and many government organizations (Sweden Post, Telecom Finland, U.K. Ministry of Defense, U.S. Jet Propulsion Laboratory, U.S. Department of Defense DISA, U.S. NIST, and U.S. Department of Defense NSA). As such it represents a broad consensus of how to organize and mature a PKI environment. In the late 1990s IBM organized their PKI security solutions around
217 the APKI and continued to develop profiles and enhancements to it. The Trust Infrastructure for Europe (TIE) project uses the APKI as an organizing mechanism.
Future success and usage of the APKI is dependent on the modularity of the APIs and protocols that it specifies. One of the primary goals of the APKI was to define a set of services provided by APIs and protocols that could be replaced without disturbing the rest of the services. For this to work there must be well-defined layers separated by these APIs and protocols. Monolithic solutions, such as SSL, hide those interfaces and make it difficult or impossible to replace specific security services. The IETF PKIX protocols, which by nature are self contained and have well-defined access points, dominate the top half of the APKI and CDSA, which also has a well defined boundary dominates the bottom half.
A second factor that affects the usability of the APKI is the lack of defined profiles. A profile is a specification, derived from an API or protocol standard that specifies the exact options to use. The use of profile enhances interoperability between different vendors products. As an example the lack of profiles and the loose definitions in SMIMEv2 made it possible for different vendors to comply with the standard and still not interoperate.
Finally the interoperability of the different layers is influenced by activity of the vendors themselves. Some vendors have implemented the APIs specified in the APKI in such a way that their interfaces are not open to outside programmers or security software from other vendors. This is often done to lock customers into one vendor for all of their PKI products.
Because of its flexibility, the APKI will continue to be useful to describe the architecture of PKI based security systems. Even proprietary systems can be defined within the group of API functions. Microsoft’s Windows 2000, for example, uses IPSec protocols, layered on top of both IETF PKI protocols and also on top of the MS-CAPI API (instead of CDSA) to provide session-oriented security.
The APKI should be used as part of a security design architecture. It would not normally be referenced in products or security services. It would also be most likely to be used by customers to organize their internal PKI projects. Therefore it is not likely to be mentioned much in vendor product literature.
Future usage of the APKI also depends on the success or popularity of PKI itself. Various problems with PKI, including scaling, the binding of identities to keys, complexity and interoperability problems have significantly slowed the growth and usage of PKI security systems.
As we look at the criteria used to judge the APKI it appears to be in the Growth part of its life cycle, although this doesn’t mean that it will move to the next stage. See the table below for where the APKI ranks in different measures of maturity.
APKI Idea Proof of Growth Maturity Decline Concept Market None 1%1%---5%5% 5%-30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership
218 Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic IImprovingmproving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – Follow on work in the Open Group has been directed by the members to the writing of security patterns rather than a revision of the APKI. It is not likely that there will be a new edition or any other changes to the APKI itself. Still it remains a useful architecture for organizing the components of a public key infrastructure.
A3.2 PKCS#11 (Public-Key Cryptography Standard) PKCS#11 is a very mature standard among the different cryptographic APIs. Nearly every hardware vendor supports PKCS #11 and there are several vendors that run compliance testing programs. Many software applications use this interface as a mechanism for accepting the hardware tokens that it supports. Other smart card standards such as the Open Card Framework (OCF) can be used with PKCS#11.
In addition to support from vendors and third party solution providers, RSA Security continues to host PKCS#11 workshops to expand the use of the standard and continues to mature its features.
Specific attributes of PKCS#11 are indicated below.
PKCS#11 Idea Proof of Growth Maturity Decline Concept Market None 1%-5% 5%-30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change
219 Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – For interfacing smart cards or other hardware tokens to operating system services or security applications there is no real alternative to PKCS#11. Periodic revisions have kept it up to date by adding new functions and support for new cryptographic algorithms. There will be strong support in the future and no significant alternatives to PKCS#11.
A3.3 GCS-API (Generic Cryptographic Services API) Although several implementations exist, the GCS-API is not recommended for new products or cryptographic services. The GCS-API was developed when PKI technology was in its early stages and therefore it does not support advanced key management features. The most important feature missing from it is any support for certificates.
There may be niche markets for GCS-API functionality, but they will be limited. The GCS-API has been replaced by CDSA which offers a much more complete set of cryptographic services. Much of the work done to create this API was later used as a starting point for the effort that led to CDSA. The GCS-API never progressed from a preliminary specification to a final specification.
The functions described by the API are well specified as far as they go. The API is just not complete enough for most of today’s requirements.
GCS-API Idea Proof of Growth Maturity Decline Concept MaMarketrket None 1%1%---5%5% 5%-30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology
220 Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – This API is not recommended for general use. There is no support in the API for certificate management.
A3.4 CDSA 2.0/2.3 (Common Data Security Architecture) CDSA has had some significant successes and has at the same time been slow to take off. When CDSA was under development, it had significant support from the major Unix vendors and several of the specialized security providers. Intel, IBM and Apple made large investments in the technology.
CDSA contains a very comprehensive set of APIs and services. It is expandable, with an architecture that supports plugin components. New technologies and algorithms can be added. For example a key recovery service was created as a plugin. Biometric data authentication services were also created as a plugin. SPKI (Simple Public-Key Infrastructure) mechanisms have been added also.
The down side of CDSA is that it is a very large API with hundreds of calls. This is probably unavoidable given the flexibility and capability that were its goals. Nevertheless, this has slowed its acceptance.
A second factor that slowed the acceptance of CDSA was the reluctance of major cryptographic venders to use or expose CDSA APIs. Several major vendors were involved with the development of CDSA, including RSA Security, Entrust Technologies and Baltimore Technologies, yet many of them have either hidden CDSA beneath their own APIs or abandoned it in favor of their proprietary APIs. This was part of a general movement in the late 1990s by vendors to lock in their customers and is one of the reasons for the recent decline in PKI technology sales.
CDSA still remains the most complete and expandable choice for providing cryptographic based security services and vendors continue to support it. Intel continues to develop new applications that depend on CDSA such as their new Boot Integrity Services (BIS) application. IBM, HP and Apple continue to use it in their security products.
CDSA Idea Proof of Growth Maturity DecliDeclinene Concept Market None 1%-5% 5%5%---30%30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope
221 Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plupluss Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – The CDSA API is the most complete and flexible set of APIs for cryptography based security services. It is easily expandable. Its difficulty lies in its size and learning curve. Usage of CDSA will continue to grow.
A3.5 CDSA/HRS (Common Data Security Architecture/Human Recognition Services) The CDSA/HRS API has not seen a lot of use, primarily because of the slow growth in the biometric industry. This is expected to pick up in the near future. For too long the biometric market has been driven by hardware manufacturers who have built devices. Integration of these devices beyond simple demonstration programs into enterprise security systems has been a slow process.
The use of CDSA/HRS to integrate biometric devices with PKI systems has a lot of promise and would provide an integrated software and hardware security solution.
CDSA/HRS Idea Proof of Growth Maturity Decline Concept Market None 1%1%---5%5% 5%-30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change
222 Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – There will be slow growth in this area, partly because CDSA/HRS is dependent on the acceptance of CDSA itself. This area is waiting for a successful widely used application. It is important for CDSA/HRS to succeed to provide common ground between software (PKI) authentication systems and hardware (biometric devices) identification systems. It is not certain that it will.
A3.6 BioAPI The BioAPI, although related to the CDSA/HRS API does not depend on the acceptance of CDSA and its use will grow significantly faster. The standardization of implementations of the BioAPI is helped because of a freely available reference implementation. The BioAPI Consortium does not do any conformance testing of those products that claim to be compliant.
There are currently several products that conform to the BioAPI. These include face recognition, fingerprint identification and signature recognition devices.
Bio-API Idea Proof of Growth Maturity Decline Concept Market None 1%-5% 5%5%---30%30% Saturation Declining Penetration Geographic Isolated Local RegioRegionalnal Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
223
Conclusion – As more biometric devices come into use, the BioAPI will become more prominent. Expect to see more and more BioAPI compliant hardware devices. In September the BioAPI was submitted to the ANSI fast track standard process. Becoming an ANSI standard will further increase the BioAPI’s market share.
A3.7 GSS-API (General Security Services API) The GSS-API has been in steady use for a few years now. New security protocols that need security services tend to reference the GSS-API specification. The IETF continues to develop both new protocols and enhancements to existing protocols that will depend on the GSS-API.
The references to the GSS-API do not always appear in product specifications, although they may list GSS-API compliance. References to the GSS-API are usually mentioned when requirements for upper level security services are listed. There are currently nearly fifty published RFCs that either describe enhancements to the GSS-API or describe new protocols that rely on using the GSS-API. The enhancements are described in Section 3 of this report. Some of the protocols that specify the GSS-API are:
RFC 1961 describes a GSS-API based authentication method for use with Version 5 of the SOCKS protocol. The SOCKS protocol is used to allow authenticated access through firewalls. RFC 1961 was written for the original version of the GSS-API.
RFC 2203 describes a protocol called RPCSEC_GSS that allows RPC (Reverse Procedure Call) mechanisms to use the GSS-API. The RPC mechanism supported by this protocol is the Open Network Computing (ONC) RPC, defined originally by Sun Microsystems. RFC 2695, an informational RFC, was later issued to describe how attacks on the RPC mechanism could be prevented by using the RPCSEC_GSS and GSS-API standards.
RFC 2228 defines extensions to the File Transfer Protocol (FTP) that call the GSS-API to provide strong authentication, integrity and confidentiality services when a file is retrieved using FTP.
RFC 2623 Specifies how NFS (Network File System) uses RPCSEC_GSS (described in RFC 2203 and mentioned above in this report) with Kerberos Version 5 to add security to the network file system. RFC 3010 is the standard that describes NFS Version 4 and it includes the usage of the GSS-API with three optional keying mechanisms: Kerberos V5, LIPKEY and SPKM.
RFC 2847 describes a method of using the GSS-API to supply a secure channel between a client ands a server with the client being authenticated using a password and the server being authenticated using a public key certificate. This is provides functionality similar to the SSL (Secure Sockets Layer) or TLS (Transport Layer Security) protocols. This mechanism is called LIPKEY – Low Infrastructure Public Key Mechanism.
RFC 2930 specifies a method of authenticating DNS (Domain Name System) queries and responses using shared secret keys with the GSS-API.
224 There are several current Internet drafts that also specify the use of the GSS-API. These include the following:
Draft-ietf-ipsec-isakmp-gss-auth-07, a GSS-API based authentication method for use with the Internet Key Exchange (IKE) key management protocol. IKE is the key management protocol that is currently used when implementing IPSec (IP Security) encryption. IKE, itself is under going a revision at this time.
Draft-ietf-cat-iakerb-08, an initial and pass though authentication system that uses the GSS-API with Kerberos Version 5.
Draft-swift-win2k-krb-user3user-03, a user-to-user authentication system that uses the GSS-API and Kerberos Version 5.
Draft-galb-secsh-gssapi-01, an authentication method for the SecSH (Secure Shell) protocol that uses the GSS-API.
GSS-API Idea Proof of Growth Maturity Decline Concept Market None 1%-5% 5%5%---30%30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use OpOpenen Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology RelReliabilityiability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – The GSS-API is the market leader for generic security services. Because new protocols and APIS are being developed that reference or call the GSS-API functions, this will continue to be the case.
225 A3.8 IDUP-GSS-API (Individual Data Unit Protection – Generic Security Services API) The IDUP-GSS-API is designed for protecting individual pieces of data. Its main use is for protecting e-mail. To date it has not seen a lot of use. RFC 2479, which describes IDUP, is an informational RFC and not a specification.
IDUP-GSS-API Idea Proof of Growth Maturity Decline Concept Market None 1%1%---5%5% 5%-30% Saturation Declining Penetration Geographic Scope Isolated Local Regional Global Pockets Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium LoLoww Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – Since the RFC describing IDUP-GSS-API is informational, it is less likely to be referenced. And since e-mail is a subset of the overall uses for the GSS-API, there is less likelihood that there will be many references to the IDUP-GSS-API. Nevertheless it remains a good alternative for using the GSS-API with e-mail or data files.
A3.9 XGSS-API The XGSS-API was never released as an RFC by the IETF. Nevertheless the opinion of those who involved in authorization work at the IETF is that it complements, more than competes with, the GAA-API and AZN-API.
XGSS-API Idea Proof of Growth Maturity Decline Concept Market None 1%1%---5%5% 5%-30% Saturation Declining Penetration
226 Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – The XGSS-API will be used in some products and have some limited acceptance as a standard. Although the draft never became a released standard, it is quoted or referenced a number of time in the literature and will have some influence.
A3.10 GAA-API (Generic Authorization and Access Control) API The GAA-API is designed to facilitate authorization decisions by applications. An application would use the GAA-API functions to determine if a requested action is authorized and also to request additional access control information about a specific resource.
The GAA-API will continue to be referenced in papers and other follow on authentication work. It will also be implemented in some products and used by other technologies; but like the XGSS-API the specifications drafts were never released as finished RFCs.
GAA-API Idea Proof of Growth Maturity Decline Concept Market None 1%1%---5%5% 5%-30% Saturation Declining PenetratiPenetrationon Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts Completed Revisions TechnolTechnologyogy Very High High Medium Low Frozen Change
227 Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
Conclusion – The GAA-API will continue to exert some influence on authorization technology although it likely will not get a large market share.
A3.11 aznAPI (Advanced Authorization API) Of the authorization standards discussed in this report, only the aznAPI has been released as a formal standard. At the same time as the aznAPI specification was being written, software was being developed by DASCOM and so the aznAPI has the benefit of testing while it was in progress.
The aznAPI provides the interface between Access Decision Functions (ADF) and Access Enforcement Functions (AEF) as defined by the ISO authorization model that is specified in ISO/IEC 10181-3. This gives the aznAPI greater flexibility than competing authorization APIs.
The aznAPI also has an advantage with the DASCOM product, now a product of the Tivoli division of IBM Corporation. This is one of the better selling authorization products and has been adopted by several large end user corporations.
aznAPI Idea Proof of GroGrowthwth Maturity Decline Concept Market None 1%-5% 5%5%---30%30% Saturation Declining Penetration Geographic Isolated Local Regional Global Pockets Scope Ownership Proprietary Limited Use Open Use Open Source No Ownership Standards None Informal Formal Formal Formal plus Drafts ComCompletedpleted Revisions Technology Very High High Medium Low Frozen Change Supporting Nascent Developing Developed Mature Legacy Technology Supporting Unknown Erratic Improving Steady Decreasing Technology Reliability Products None A Few Significant Market Decreasing Market Leader Share
228
Conclusion – The aznAPI has the advantage of being used by a well-established authorization product (Policy Director from the Tivoli Division of IBM Corporation). As companies look for interoperable authorization solutions some will use Policy Director and therefore the usage of the aznAPI will grow.
A3.12 General Note on Authorization Standards All three of the authorization APIs discussed here (XGSS-API, GAA-API and AZN-API) are workable specifications for implementing standard authorization functionality in applications. Yet none of these has seen widespread acceptance and the growth in this market area has been very slow.
This is more because of the difficulty of creating widespread solutions in this area than the fault of any of these APIs. Authorization, as a standard function that interoperates with multiple applications and operating systems has not yet achieved any success. This is not because the user community doesn’t want this capability but is the result of a fragmented vendor community.
This will probably change in the next decade as connectivity becomes greater and authentication systems mature to provide the support needed by the authorization systems.
229
付録 4. セキュリティ関セキュリティ関連連 API の分類と比較 (補足)
ここでは 2. セキュリティ関連 API の分類方法 および 4. セキュリティ関連 API の比較 に関連する参考情 報として、これらに関連するプロジェクトの調査結果や文献をまとめる。
A4.1 NSA Cross Organization CAPI Team セキュリティ関連 API の比較については、NSA Cross Organization CAPI Team が調査を行っており、こ の結果が [374], [375], [376] の報告書にまとめられている。 この報告では、GSS-API/IDUP-GSS-API、X/OPEN GCS-API、Microsoft CryptoAPI、RSA CRYPTOKI の 4 つの代表的な API について、Cryptographic Awareness の尺度でこれらを階層化すると同時に、アル ゴリズム独立、暗号モジュール独立、Cryptographic Awareness、モジュラーデザインと付加サービス、 MISSIi サポート、Safe Programming、Security Perimeter の観点から 4 つのセキュリティ関連 API を 比較し、CAPI 利用におけるガイドを示している。
備考) "Cryptographic Awareness" とは、CAPI (Cryptographic API) を利用する際にプログラマがどの程 度、暗号の知識が必要か、暗号を意識してプログラミングする必要があるか、のレベルを指すものである。 上位レベルの CAPI 程、暗号を意識せずにセキュリティ プログラミングを行うことができる。
A4.2 ICE ICE プロジェクトでは、1995 年から 1996 年までに 3 回の国際的なワークショップを開催しており、その 場で ICE のメンバーである各企業の代表者がさまざまな発表を行っている ([377])。その中でセキュリティ 関連 API に関連する主な情報を抽出して、以下に紹介する。
A4.2.1 第 2 回ワークショップ 1995 年 9 月 18 日‐19 日開催 ([378])。 • NSA CAPI 活動の概要と推奨 NSA の CAPI イニシアチブでは開発中の CAPI 活動を調査分析し、CAPI の階層構造によるアーキテク チャ (hierachical architecture) を提案している。また、CAPI の調査比較を行った上記の調査結果を報 告すると同時に、この分析により、「唯一の CAPI により全ての要求を満たすことはできず、これら CAPI の組み合わせが必要である」と結論付けている。 この時の推奨は Cryptoki + GCS-API + GSS-API/IDUP-GSS-API の組み合わせであった。 また、開発者の Cryptographic Awareness による観点から 3 階層の CAPI に構造化したアーキテクチ ャを提案している。 • X/Open のこれまでの進捗および今後の計画 XDSF、GSS-API、GAS-API (Generic Audit Services API)、GCS-API という 4 つの活動中の API に ついて報告している。また、HP が GCS-API の最初の実装を行っている、との報告もされている。 • Entrust の活動概要 Entrust の PKI 製品体系について報告があり、この製品体系がベースのアーキテクチャが API、メカニ ズム、実装で区別して体系化されていると説明している。ここでは API としては IDUP-GSS-API、 GSS-API、Cryptoki を利用している。 • Spyrus プログラム概要 SPYRUS SPEX/Alogrithm Aglie フレームワークについて報告。これは、アプリケーション、ライブラ リ、デバイス ドライバ、カード/ソケット サービス、カード/カードリーダの 5 階層で構成されている。 i MISSI については、用語 MISSI (Multilevel Information System Security Initiative) で解説。
230 • TIS (Trusted Information Systems) プログラム TIS では FORTEZZA カードを TIS/MOSS アプリケーションに統合し、上記の SPYRUS SPEXX/AA ライブラリを利用して様々なトークンを扱うデモを行っている。
A4.2.2 第 3 回ワークショップ 1996 年 3 月 11 日‐12 日開催 ([379])。 • NSA CAPI 活動の概要 NSA の CAPI イニシアチブ では上述の CAPI 比較調査を行っておりこの報告と共に、次のような NSA の技術スタッフによる CAPI 実装およびこれを用いた実験、セキュリティ サービス API の調査開発な どについて報告している。 • NIST の Cryptographic API と Authentication Program NIST の Advanced Authentication Technology Program は NIST Cryptographic API Project を主 催。GCS-API ベースの NIST FIPS が 1996 年第 3 四半期に予定されていたが、この採用は Microsoft CryptoAPI により影響を受け、その時点までに同意に達していない。 • X/Open GCS-API GCS-API が UNIX ベースである一方、Microsfot CryptoAPI が Windows ベースであり、この両者が収 束されるべきだと提言されている。 • Certificate Management Services API NORTEL が CMS-API (Certificate Management Services) と PKI を実装する ENTRUST 製品を紹介。 また、セキュリティ API が 3 つのレベルを持つことを説明。 - 高レベルのセキュリティ API (例えば GSS-API、CMS-API) を用いたアプリケーション - 中間レベルの暗号化ライブラリ API (例えば BSAFE) - ハードウエア モジュールをサポートする API (例えば、PKCS#11) • 64 ビット CKE 実験の提案 E メールとワープロの 2 つのアプリケーションを開発する ICE の実験を提案。この際、以下のフレーム ワークを提案している。 GSS-API | GCS-API | PKCS#11
A4.2.3 第 4 回ワークショップ 1996 年 12 月 3 日‐4 日開催 ([380])。 • ICE の Layered Security Architecture および Experimental Framework Layered Security Architecture および Experimental Framework の 2 つの説明。 • HP ICF ICF の目標は次の 3 つの問題を解決することである： - HP の輸出問題 - 国内の法が定期的に変わる問題 - 企業の開発者による暗号を実装促進する問題 • NIST が Authentication Module Interface (AMI) を提案 AMI は Advanced Authentication Technology Program が作成した Common Authentication Architecture (CAA) をベースにしており、認証機能に対する汎用のインタフェースを提供する。また、 NIST が Cygnacom と GCS-API のリファレンス実装で契約した、と報告している。 • Certificate Management API (CMAPI) の概要 Nortel の CMS-API や NSA の CMAPI などの CMAPI について説明。同時に、Intel CDSA、Sun SKI、SESAME PKM-API、Microsoft CryptoAPI 2.0 などのセキュリティ API についても報告。 • NSA の CAPI デモ GSS-API と Microsoft CryptoAPI 1.0 を用いて SPKM (Simple Public Key Mechanism) を実装する 単純なネットワーク チャットのアプリケーションをデモ。 • 実際の CAPI 実装
231 PCMCIA 暗号カードのための、RSA BSAFE を用いた Microsoft CryptoAPI 1.0 の CSP を Nguyen が開発。
また、以下の 3 つのプレゼン資料がさらに詳しい内容を伝えている。 • ICE では暗号 API(CAPI)を用いたデモ開発をしながら CAPI やこれをベースにしたアーキテクチャの 検討などを行っている。そこにおいて Cryptoki を用いたセキュアなメーラのデモ開発が行われた ([381])。 • 上述した ICE の Layered Security Architecture および Experimental Framework の図および説 明がのっている ([382])。 • [381]と同じ E メールのデモと、WindowsNT 4.0 の CSP に関して説明 ([383])。
参考として、上述で触れたセキュリティ API の 3 階層構造の図を以下に載せておく ([384])。
なお ICE 自身に関しては、付録 4.7.3 に簡単な紹介をしている。
A4.3 新しいセキュリティ アーキテクチャ提案 新しいセキュリティ アーキテクチャ設計に関して論じた論文がある ([385])。この論文では以下のような分 類をしている。 ① 暗号化に One-to-One に対応する関数インタフェースを持つ API Fortezza、libdes ② 引数により複雑さを隠した umbrella 関数によるインタフェースを持つ API BSAFE、GCS-API、Microsoft CryptoAPI、PKCS#11 ③ 認証、完全性、機密性のような特定のタイプのサービスに特化した機能を提供する API GSS-API、OSF DCE security API、SESAME API ④ アーキテクチャ APKI、CDSA
GSS-API はセッション オリエンテドな API で、他のエンティティとのセッション スタイルのコミュニケ ーションを管理するのに使う (例えば、Kerberos の GSS-API ラッパーのセットからなる実装)。
232 SESAME API は X.509 証明書サポートのようなさまざまなエンハンスメントとともに Kerberos 派生をベ ースにしている。 GSS-API がピア (peer) 間のセッション ベースのインタフェースを提供するのに対し、IDUP-GSS-API は蓄積交換型 (Store-and-Forward) をサポートする (これは典型的には email のようなサービスに利用さ れる)。
また、アーキテクチャとそれのインタフェースを提供する API と厳密に区別する必要があり、アーキテク チャとしては非常に汎用名 APKI 要求仕様と、CDSA をあげている。この論文では CDSA が唯一、汎用的 なアーキテクチャ設計を提供するアーキテクチャである、としている。
A4.4 IATF IATF (Information Assurance Technical Framework) は、NSA の ISSO Organization が政府や業界の セキュリティ関係者のサポートを受けて開発したセキュリティ ガイダンスの文献である。 この文献は、誰でもアクセスでき、インターネットで一般公開されており、IATFF (Information Assurance Technical Framework Forum) が中心となって活動している ([386])。
IATFF のサイト [387] から IATF Document 3.0 がダウンロードできる ([388])。この文書の内、"7.1.5.1.2 Cryptographic Application Programming Interfaces (CAPI)" の項にセキュリティ関連 API の分類と紹介 が掲載されている ([389])。
ここでは、CAPI を以下の 3 つのレベルに分類している。 ① ハイレベル - GSS-API ② ミドルレベル - CDSA, MS SSAPI ③ ローレベル - Cryptoki (PKCS#11), CryptoAPI, FORTEZZA CI Library
これは、CAPI の観点からの分類であり、CDSA と CSSM-API を同一とみなして分類している。
この分類は、CAPI の調査結果をまとめた資料[374]、[375]、[376]における Cryptographic Awareness の尺度 と同様の分類に基づくものであり、本調査においてはアーキテクチャ/フレームワークの分類を導入するこ とにより、より包括的な観点からの調査/分析を行うことにした。 特に、今後どのようなセキュリティ関連 API を選択するかを判断する際に、アーキテクチャ/フレームワー クの観点は重要性を増すと思われる。
233
付録 5. セキュリティ関連 API の分析 (補足)
ここでは、3. 分類に基づく各セキュリティ関連 API の分析 で調査対象としなかったセキュリティ関連 API およびそれに関連する情報を提供する。 なお、ここでは 2. セキュリティ関連 API の分類方法 で説明した分類をベースにしているが、それに該当 しない調査対象のために 2 つの分類を追加している。
A5.1 アーキテクチャ (Architecture)
A5.1.1 DII COE SSAF (MITRE Corporation) DII COE SSAF (Security Service Architecture Framework) は MITRE Corporation が開発しているア ーキテクチャである。
本文 3.2.6 COE SS API (MITRE) で簡単に触れているが、インターネットで検索する限り、[390] など 2, 3 のプレゼン資料に簡単な説明が出ているだけで、その詳細を説明する資料が入手できなかった。
This briefing describes a specification of security services for distributed applications in the Defense Information Infrastructure (DII) Common Operating Environment (COE). Security services include identification and authentication, encryption, access control, and auditing. The security services are referred to as the COE security services API (COE SS API). The framework that incorporates the COE SS API is called the Security Services Architecture Framework (SSAF).
The DII COE Security Services Architecture Framework (SSAF) enables GOTS applications to interface with the DoD PKI with a minimum of code ([391]).
A5.1.2 ICF (HP) International Cryptology Framework (ICF) は Hewlett-Packard (HP) が提唱しているフレームワーク である ([2])。 最上位にアプリケーション、2 層目に API、最下層に暗号ユニットという構成をとる。認可された政府機 関が提供するポリシーアクティベーショントークンを暗号ユニットに組み込むことで、暗号アルゴリズム が作動する仕掛けとなっている ([2])。
234
US Department of State (http://www.state.gov/) の承認を受けたセキュリティ フレームワークで、その 目的は、政府の輸出規制に対し、単一のソフトウェア製品により国内、海外の両方に対応することである ([392])。 ICF uses Microsoft's Crypto API, an interface for building secure software applications, and Trusted Information Systems' cryptographic key recovery capability.
Intel also said it would manufacture and distribute hardware that will include the ICF technology, which is based on RSA Data Security encryption. Also backing the framework are Netscape Communications, Oracle, Informix, VeriFone, and smart card manufacturer Gemplus ([392]).
資料[2]、資料[393]などでは ICF の概要が簡単に解説してあるが、現在、HP のサイトから ICF に関する情 報を入手することができない。また、インターネットで検索しても ICF に関する情報が見つからないこと から、現在 ICF に関する活動は行われていないようである。
しかも、[394]の記事では US.政府が ICF を承認しながら、暗号製品の輸出規制法の作業があまり進展して いないことと、ベンダー側の ICF 推進の動きを対比させ、記事のタイトルに書かれた "Government Cryptography Ruling Stirs Dissension - ICF is progress, but not enough, critics say" と評している。
A5.1.3 SecureWay (IBM) SecureWay は IBM が提唱しているフレームワークである。最上位にアプリケーション、2 層目にサービ ス/サブシステム、3 層目に API/ツールキット、最下層に暗号化エンジンという構成をとる。キーリカバリ 技術を容易に取り扱え、かつ既存の暗号関数を脅威にさらさない様に仕様化されている ([2])。
なお、現在、IBM のサイトで SecureWay の情報を検索する限り、IBM に買収された Tivoli のサイトから 以下の製品情報が検索されるのみで、上記のようなフレームワークとしての情報は見つからなかった ([395])。 • Tivoli SecureWay Global Sign-On • Tivoli SecureWay Policy Director • Tivoli SecureWay Policy Director for MQSeries • Tivoli SecureWay Privacy Manager
235 • Tivoli SecureWay Public Key Infrastructure • Tivoli SecureWay Security Manager • Tivoli SecureWay User Administration
現在は、以下の図のように SecureWay という製品群の名称としてのみ使われているようである ([396])。
A5.1.4 Open Service Gateway (IBM, 他) http://www.osgi.org/
米 IBM や米 Sun Microsystems など 15 社が，インターネットにつながった家庭やオフィス(SOHO)向け にサービスを提供するための標準仕様「Open Service Gateway」を策定する協議会を設立した。Java を ベースにした仕様となる。各種の API（application programming interface）を定める。
OSGi (Open Services Gateway Initiative) は非営利企業で、オープン仕様の作成や普及を行う。
The OSGi is an independent, non-profit corporation working to define and promote open specifications for the delivery of multiple services over wide-area networks to local networks and devices. The OSGi specification defines an open framework that enables multiple software services to be loaded and run on a services gateway such as a set top box, cable modem, DSL modem, PC or dedicated residential gateway. The OSGi effort was announced in March 1999. The consortium currently comprises more than 75 member organizations from around the globe. Membership is open to any interested party, including Internet Service Providers, Network Operators, Original Equipment Manufacturers, Independent Software Vendors, end users, academic institutions, government agencies, and non-profit organizations.
OSGi announces its Service Gateway Specification 1.0 ([397]).
Q6. What is being standardized? The OSGi is a collection of APIs that define standards that define a services gateway. These APIs define a set of Core and Optional APIs that together define an OSG compliant gateway. Where possible the OSG is leveraging existing Java standards. Where there are standards that apply that are not Java based, the group's work focuses on integrating with these standards.
The core APIs address service delivery, dependency and life cycle management, resource management, and remote service administration. All of the core APIs are either contributed by a member or developed by the OSG technical working groups. The optional set of APIs define mechanisms for exporting resources to an HTTP-based web server, client interaction with the gateway and data management.
236 参考として上記のページ [397] から以下の 2 つの図を引用しておく。
図. OSGi と関連標準
図. OSGi フレームワークおよび仕様
また、[397] のページから以下の仕様書がダウンロードできる。 • OSGi's Specification Overview. • OSGi's Service Platform Release 2. • the Adobe Certificate for OSGi's Service Platform Release 2. • OSGi's Service Gateway 1.0 Enhancements and Service Platform Release 2 Overview.the Service Gateway 1.0 Overview.
237 A5.1.5 TCPA, (Compaq, 他) http://www.trustedpc.org/home/home.htm
The Trusted Computing Platform Alliance (TCPA) was formed by Compaq, HP, IBM, Intel and Microsoft. All five companies have been individually working on improving the trust available within the PC for years. These companies came to an important conclusion: the level, or "amount", of trust they were able to deliver to their customers, and upon which a great deal of the information revolution depended, needed to be increased and security solutions for PC's needed to be easy to deploy, use and manage. An open alliance was formed to work on creating a new computing platform for the next century that will provide for improved trust in the PC platform.
現在、"TCPA Main Specification v. 1.1a" が公開されており、ユーザ登録により仕様書を入手することが できる。
A5.2 セキュリティ サービス API (Security Service API)
A5.2.1 PICA (RSA)
PICA (Platform-Independent Cryptography API) は Apple、IBM、JavaSoft、Motorola、Netscape、 Nortel、Novell、RSA、Silicon Graphics が共同で発表した RSA の PKCS 上で構築される API である。 1996 年 10 月の発表以降、詳細は不明。 ホームページは http://www.rsa.com/PRESSBOX/releases/pica_rel_101796.html 等 ([2])。
IT Companies Band Together on Joint Cryptography Specs Several key information technology companies Oct. 17 announced their support for a security effort code-named Platform Independent Cryptography API (PICA). Apple, IBM, JavaSoft, Motorola, Netscape, Nortel, Novell, RSA, and Silicon Graphics jointly announced their support for PICA which builds on RSA's widely-adopted Public Key Cryptography Standards (PKCS) process and technology submissions from several companies. The PICA alliance has been formed primarily to address potential interoperability problems that may arise as encryption technology moves into the mainstream software products of competing vendors. Open development meetings are scheduled for later on this year, and PICA vendors will attempt to "build bridges" between their differing cryptography approaches. The new PICA specification aims to allow developers to introduce open, cross-platform, application independent security in the same way that they introduce other features like graphics, communications, and networking protocols, boosting EDI and electronic commerce security capabilities. [398]
[399]の記事から IBM の SecureWay、CDSA の関係を示す部分を引用しておく。 This is an exciting time for cryptography. The PICA effort willbetter enable IBM's SecureWay cryptographic infrastructure to providea less complex, more modular way for developers to build applicationswhich make the Internet safe for business," said Kathy Kincaid, Director of I/T Security Programs for IBM.
This will do for security what html did for the Web," said MikeHomer, VP Marketing for Netscape. "Netscape is happy to announce that our client and server security infrastructure is built on Intel's CDSA, a potential building block for PICA. We selected CDSA because it has three attributes which are important to Netscape products -- openness, interoperability and cross-platform support."
備考) 資料[2] から引用した上記 URL は現在アクセス不可になっているが、 [399] の URL でアクセスでき る。なお、、インターネットで検索する限り、PICA で検索される情報はほとんどなく、もはや活動してい
238 ないようである。このため、どの分類に属するかを判断する情報が入手できないため、資料[2]に従いセキ ュリティ サービス API に分類しておいた。 記事[400] の PICA will be built on RSA Data Security's public-key cryptography framework, as well as contain input from other vendors. や、記事[401] の PICA, which will be built on RSA's public key framework and input from other vendors, is aimed at quelling the confusion of all these encryption APIs and finding a way to make sure there's one that everyone can implement for public-key cryptography. Although it probably won't be final for another year, PICA is expected eventually to replace these individual vendor APIs. の情報から、フレームワークではなく API として位置付けた方が妥当と思われる。
ただし、資料[402] では、PICA を暗号 API (Cryptographic API) に位置付け、この暗号 API を用いてより 上位の API が構築される、としている。また、ICE の [377] においても、暗号 API に分類している。
1996 年の段階では、要求仕様を集め、既存のセキュリティ API/アーキテクチャ (MS CAPI, CDSA, GSS-API, GCS-API) の調査を行い、広くアドバイスを求めている段階であった ([248])。
A5.2.2 High-Level PKI Service API (NIST and FDIC) 公開鍵ベースの暗号サービス ([403])。
The PKI Group is currently working with the Federal Deposit Insurance Corporation (FDIC) to develop a high-level Application Programming Interface (API) for public-key based cryptographic services. Currently, PKI-enabled applications must use proprietary, vendor-provided APIs to interface with their PKI, thus making support across multiple PKI products difficult. To facilitate the development and wide-deployment of PKI-enabled applications, NIST and FDIC are working to make this interface to a PKI consistent, regardless of the PKI product being used. If each PKI product and each application can meet at a common interface, more applications will become PKI enabled for all PKIs.
The following picture shows the context for the high-level API.
4/17/2001 作成の仕様書がダウンロード可 ([404])。以下に関数の簡単な説明の表を示しておく。
Call Purpose signBuffer() Generates a digital signature over the information provided in a buffer using the algorithms specified within the originator's certificate signFile() Generates a digital signature over the information provided in a file using the algorithms specified within the originator's certificate verifyBuffer() Verifies a digital signature that was generated over the information provided in a buffer using the originator's certificate information verifyFile() Verifies a digital signature that was generated over the information provided in
239 a file using the originator's certificate information encryptBuffer() Encrypts the information provided in a buffer using a symmetric key that is subsequently encrypted using the recipient's public encryption key encryptFile() Encrypts the information provided in a file using a symmetric key that is subsequently encrypted using the recipient's public encryption key decryptBuffer() Decrypts the symmetric encryption key provided in an encoded object using the recipient's private encryption key and then decrypts the information provided. decryptFile() Decrypts the symmetric encryption key provided in an encoded object residing on a file using the recipient's private encryption key and then decrypts the information provided CMSBufferParser() A non-cryptographic function to faciliate parsing encoded message in a buffer CMSFileParser() A non-cryptographic function to faciliate parsing encoded message in a file
A5.2.3 SGSS-API SGSS-API は SESAME 用に GSS-API を拡張した API 仕様である ([405])。
Abstract: SESAME - Secure European System for Applications in a Multi-vendor Environment - is an authentication system that extends Kerberos by supporting public-key cryptography, role-based access control, attribute certificates, delegation, and extensive auditing. Additionally, SESAME incorporates a standard interface for program developers which is based on the Internet standard Generic Security Services Application Programming Interface (GSS-API) (followed by RFC 1508, and finally RFC 2078).
UIUC SESAME is a portable version of SESAME fully implemented in Java. Accordingly, a Java implementation of SESAME GSS-API is needed. This will act as an interface for applications utilizing UIUC SESAME, as well as a way to hide UIUC SESAME's implementation details from callers. This document is concerned with the use and implementation details of SGSS-API (SESAME GSS-API).
[406]、[407] に SGSS-API の仕様がある。
API: 以下の 9 クラス、112 メソッド ([408])。 ① class Oid (8 メソッド) ② class GSSManager (4 メソッド) ③ class GSSName (11 メソッド) ④ class MessageProp (10 メソッド) ⑤ class GSSCredential (20 メソッド) ⑥ class ChannelBinding (6 メソッド) ⑦ class GSSContext (42 メソッド) ⑧ class GSSException (6 メソッド) Extensions: ⑨ class GSSAttribute (5 メソッド)
備考) なお、XGSS-API 対応のメソッドを含む。
以下、[409], [410], [411] から引用。 SESAME は欧州の R&D プロジェクトであり、RACE プログラムの下、European Commission により一 部の資金提供を受けていた。(しかし、メインの研究者はもはや加盟しておらず、SESAME に関する 研究開発も既に終了してしまっている) 。また、このプロジェクトの成果である技術も SESAME と呼ばれ る。 SESAME 技術は交換データの暗号による保護と追加された分散アクセス管理機能による洗練されたシン グル サインオン (Single Sign-On)を提供する。 SESAME は構築キットであり、製品開発者にとってはセキュリティ インフラストラクチャのセットであ
240 る。フルに管理されたシングル サインオン製品がこれ上に構築される、基礎となる基盤を提供する。
そのような製品の例としては、 • ICL's Access Manager • Bull SA's Integrated System Management AccessMaster (ISM AccessMaster). があり、Siemens (Software & Systems Engineering Ltd) は SESAME 技術を用いてセキュア X.400 mail 製品群を改良した。
また、US のイリノイ大学アバーナ-シャンペイン校 (UIUC) ([412]) で UIUC SESAME という UIUC 版 SESAME に関しての研究を過去行っていた。上記の [405] はその研究成果である。
A5.2.4 Java SASL Java SASL Specification specification defines a SASL client and server API in the Java programming language.
JSR (Java Specification Requests) して [413] で策定中の仕様である。
SASL は IETF が RFC2222, "Simple Authentication and Security Layer (SASL)" として標準化の規格 をまとめているプロトコルで、GSS-API、Kerberos Version4、S/Key による認証メカニズムを持ってい る ([414])。なお、 RFC 2222 は RFC 2444 で更新されたとなっているが、 RFC 2444 の仕様には RFC 2222 での説明が含まれていない ([415])。
A5.3 暗号 API (Cryptographic API)
A5.3.1 CryptoAPI 1.0 (Microsoft) CryptoAPI 1.0 は、本文 3.2.2 CryptoAPI 2.0 (Microsoft) で簡単に触れている。
CryptoAPI 1.0 は、アプリケーションから暗号アルゴリズムを意識せずに暗号を作成するための API とし て Microsoft により定義された。この仕様は、鍵管理、暗号処理、デジタル署名用に 21 個の API が用意 されている ([2])。
A5.3.2 SNAPI, Netscape Netscape 社が提唱する API で、Microsoft の CAPI 対抗として開発された API である ([416])。 また、INTAP の H8 年度報告書、Appendix2 の Netscape の発表した図がある ([2])
241
なお、Netscape のサイトで検索する限り、SNAPI に関する情報が見つからないため、現在この API に関 しての活動はされていないようである。
以下、[416] より情報を引用しておく。
Netscape hopes this quarter to make available a set of security interfaces for Communicator 1.0 that lets Web-based applications securely communicate with servers over IP-based networks.
Netscape's set of interfaces, code-named Security Native API (SNAPI), will complement Intel's Common Data Security Architecture, which Netscape announced support for in October. Since then, sources said, the companies have been working in sync on their architectures, and Intel appears to be favoring SNAPI over Microsoft's CryptoAPI (CAPI).
<略>
At the RSA conference, Netscape will demonstrate an early implementation of SNAPI with VeriSign, Litronic, Consensus, and Hewlett-Packard. Netscape will integrate SNAPI with Secure Sockets Layer, which provides for authentication and encryption channels for applications over TCP/IP, and Secure MIME, which encrypts e-mail messages.
SNAPI is designed for high- and low-level security services that could be implemented in software or hardware and are used to manage cryptographic keys, store certificates, and define security policies.
A5.4 認可 API (Authorization API)
A5.4.1 Pluggable Non Interactive Authentication Modules (PNIAM) 3.4.5 PAM (SunSoft) を拡張した API ([417])。
It provides applications with a generic interface to authentication related functions. Actions to be done for each authentication request are specified by a system administrator in terms of dynamically loaded modules. PNIAM design incorporates best ideas of PAM (Pluggable Authentication Modules) project. The main difference between PAM and PNIAM is the target. The main target of PNIAM is a clear and reliable authentication scheme for Internet servers. Internet protocols usually specify a
242 fixed set of requests and replies between the server and the client. It makes the interactive authentication hardly possible. PNIAM deals with a set of requests and replies rather than interacts with the user. That's why words ``Non Interactive'' are in the name.
A5.4.2 PERMIS API
PERMIS (PrivilEge and Role Management Infrastructure Standards Validation) ([418])
Electronic transactions - be it between Public Administrations, citizens or businesses (for example G2C, G2B, B2B) - depend upon solving two kinds of issues: ([419])
PERMIS is validating the use of Privilege Management Infrastructures (PMI) based on the X.509 (2001) standard. Three very different applications will be built in the cities of Salford, Bologna and Barcelona, and all will use the same PMI infrastructure to validate its general applicability and usability. The project will attempt to standardise the privileges needed for Internet E-commerce applications and publish an Internet RFC describing these and PERMIS API. ([420])
プレゼン資料 [421] では、X.812/ISO 10181 アクセス管理フレームワーク (Access Control Framework) において、ADF API の例として、aznAPI (Open Group)、GAA-API (IETF)、PERMIS API の 3 つをあげ ており、また aznAPI と PERMIS API のシステム構成の違いを説明している。 また、この資料では PERMIS API の概説として、以下をあげている。 • 4 つの基本関数： Initialise, GetCreds, Decision, Shutdown • Java で書かれ、aznAPI (Open Group) をベースにしている
A5.4.3 Intel Protected Access Architecture (Intel) http://developer.intel.com/design/security/paa/paa.htm
ノート PC 向けセキュリティ アーキテクチャ、PAA。
The services enabled by this architecture, defined in "the IntelR Protected Access Architecture Application Interface Specification", act to keep unauthorized persons from ever "getting inside" a computer or its hard disk drive (HDD). It does this by providing a generic "Plug-in" architecture enabling the latest authentication technology to be used to help prove the identity of the user. Examples of this technology include biometrics such as fingerprints and tokens such as smart cards and USB keys.
API 仕様書が [422] よりダウンロード可能。この仕様書に以下の記述がある ([422])。 This document outlines a method to help reduce PC theft by "strengthening" use authentication during the PC "boot" process. it describes an architecture, a high-level programming interface to authentication devices and protected storage, as well as common interface elements needed to support the high level interface. It is intended that PC BIOS programmers and authentication device manufacturers cna use this specification to help make pre-boot user authentication solutions compatible across PC platoforms.
備考) アーキテクチャという名が付いているが、[422] の仕様書は関数インタフェースを規定しているため、 この分類に入れた。ただし、PC ブート時にユーザ認証する BIOS や認証デバイス製造メーカを対象にした ものであるため、アーキテクチャとはいえその対象領域は非常に限定されている。
243 A5.5 バイオ認証 API (Biometric API)
A5.5.1 BAPI (I/O Software) 米 I/O Software，Inc.が提唱するバイオメトリック認証用 API。 現在は、BioAPI Consortium が BAPI と後述の HA-API をベースに BioAPI として策定を進めている。
BAPI は、ソフトウェア・アプリケーションとバイオメトリック デバイスが通信する場合のアプリケーシ ョンインタフェースを定義しており、I/O Software 社がバイオメトリックスのハードウェア、ソフトウェ アベンダーに声をかけて組織したワーキンググループによって提案されている。MS-Windows アプリケー ションが印刷を行う際、標準のドライバ・インターフェースを通して個々のプリンターと通信するのと同 様に、アプリケーションがバイオメトリックスを利用した高度なセキュリティを実現する際の互換性、統 一性を確保することによって、識別デバイスの仕様・性能等を意識することなく効率的な開発を行えるよ うにすることを目的としている。 なお、BAPI はデバイス固有の機能の使用有無によって使い分けられる 3 つの機能的に異なるレベルから 構成されている ([353])。
また、BAPI の構成図を [355] から以下に引用しておく。
A5.5.2 HA-API (National Registry) HA-API は、個人の認証や識別のためのバイオメトリック技術を組み込むソフトウェア アプリケーション のインタフェースを定めたものである。もともと National Registry 社が米国防総省の依頼により開発し た仕様であるが、後に世間に幅広く普及させることによって、バイオメトリック技術の相互互換性が確保 されるよう、一般に公開されている。1997 年 8 月 27 日に Rev.1.0 が作成されたあと、1998 年 4 月 22 日に Rev.2.0 までが発表されている。 HA-API は、プラットフォームや機器に依存しない仕様となっており、アプリケーションの開発や、装置 の変更に容易に対応できるようになっているほか、複数のバイオメトリック技術を、単独のみならず組み 合わせてサポートすることも可能である ([353])。
244 http://www.biometrics.org/Meetings/BC10/Tilton/ http://www.tritonsecure.com/haapi.html specification that defines a generic biometric interface between a software application that may want to incorporate biometric technology for identification and authentication (I&A) of an individual
また、HA-API の構成図を [355] から以下に引用しておく。
A5.5.3 指紋照合統一規格 API http://www.systemneeds.co.jp/paso/fapi/ronbun-3.htm IPA 次世代デジタル応用基盤技術開発事業 システムニーズ（株）他 本人認証規格統一協議会(PASO)
FAPI (Fingerprint Aware Application Program Interface)
指紋認証装置用の API。FAPI は，米国におけるバイオメトリックス認証の標準規格「BioAPI」とも互換 性があるように設計されている。FAPI 用ドライバ・ソフトウエアを搭載した認証装置を，BioAPI 対応の アプリケーション・ソフトウエアで制御できる。BioAPI は米 Compaq Computer Corp.や米 Intel Corp. などが推進するバイオメトリックス認証の標準規格である (00.3.27 号) 。
8 社のベンダー： オムロン、システムニーズ、シュルンベルジェ、ソニー、翼システム、東芝、日立製作所、三菱電機。
A5.6 製品
A5.6.1 RSA BSAFE (RSA Security) RSA Security が提供するセキュリティのソフト・ハード製品向けの開発キット。
245 RSA BSAFE には、C 言語用のツールキットと Java 用のツールキットがある。 提供されるものは、ライブラリ(C ライブラリまたは Java クラスライブラリ)、サンプルコード、マニュア ルである。特に、サンプルコードはソースコードでの提供となるので、RSA BSAFE の利用方法（実際の コーディング方法）を理解する際に役立つ。
準拠する標準は以下の表 ([423])。
Product Supported Standards RSA BSAFE CertCert---C,C, CertCert---JJ PKCSPKCS: 7, 10, 12 RSA BSAFE CryptoCrypto---CC ANSIANSI: X9.30:1, X9.30:2, X9.31, X9.52, X9.62. (formerly BSAFE) IEEEIEEE: P1363. PKCSPKCS: 1, 5, 8, 11, 12 NIST (FIPS)(FIPS): 46-2, 81, 180-1, 186. RSA BSAFE CryptoCrypto---JJ PKCSPKCS: 1, 5, 8, 12. (formerly JSAFE) NIST (FIPS)(FIPS): 46-2(DES), 180-1(secure hash standard). RSA BSAFE S/MIMES/MIME---CC IETFIETF: S/MIME, X.509. (formerly S/MAIL) PKCSPKCS: 7, 10.
正式なライセンス契約前に、製品の詳細情報やプロトタイプ開発をしていただくための評価版を定価 98,000 円（消費税別）で提供しています。評価期間は、6 ヶ月となる。
RSA Data Inc.はアプリケーション開発ツール群を次のような LOCT (Layered Open Cryptography Toolkit) という概念の元に開発している ([2])。
"Complete e-Business Security for Your Applications"というパンフレットがダウンロード可(済)。 http://www.watch.impress.co.jp/internet/www/article/2000/0419/rsa.htm 米 RSA Security は 18 日、暗号ソフト開発キットの新版「RSA BSAFE Crypto-C 5.0」と「BSAFE Crypto-J 3.0」を発表した。Microsoft の Windows 2000 と Sun の Solaris 8.0 に対応している。 新版は、製品版の RC6 アルゴリズムに対応している。米商務省傘下の標準化組織「National Institute of Standards and Technology(NIST)」が、現在の暗号標準方式「DES」に換わる次世代暗号標準方式「AES」 の選考を進めているが、RC6 は、5 つの最終候補の中の 1 つとして挙げられている。 RSA BSAFE Crypto-C 5.0 は暗号エンジンで、暗号や認証機能など、複数のアルゴリズムを提供する。 RSA や DES、RC2、RC4、RC5、RC6、DES、3DES、楕円曲線暗号に加えて、デジタル署名とデジタル 認証機能に対応する。 RSA BSAFE Crypto-J は公開鍵暗号標準方式の「PKCS」に準拠し、共通鍵暗号方式の Java 版が含ま れるほか、DES と SHA1 アルゴリズムが組み込まれている。
246 http://www.rsasecurity.com/products/basfe/index.html
RSA、Java アプリケーション開発用セキュリティ･コンポーネント RSA BSAFE SSL-JTM と RSA BSAFE Crypto-JTM を発売開始 http://www.rsasecurity.com/japan/news/data/199903161.html
RSA S/PAY SET エンジンのためのツールキット。S/PAY の日本版 J/PAY も発表。
A5.6.2 SECUDE (GMD Darmstadt) SECUDE 開発キットは共通鍵および公開鍵暗号化の機能を提供するライブラリである。 http://www.darmstadt.gmd.de/secude/ SECUDE is another full-featured security toolkit, from SECUDE Sicherheitstechnologie Informationssysteme GmbH.
The SECUDE development kit is a library that offers well known and established symmetric and asymmetric cryptography for popular hardware and operating system platforms. The development kit consists of a set of functions which allows the incorporation of security efficiency in practically any application (e.g. client/server, e-mail, office applications) and a documentation in Hypertext Markup Language (HTML) which describe in detail the C programming interface. There are also various commands collected in a security command shell to ensure an immediate deployment of security ([424]).
SECUDE development kit provides: • asymmetric cryptographic functions such as RSA, DSA • symmetric cryptographic functions such as DES, Triple DES, IDEA, RC2, RC4 • hash functions such as SHA, SHA-1, MD5, RIPEMD-160 • Diffie-Hellman key agreement • security functions for proof of origin, data integrity, non-repudiation and confidentiality on the basis of digital signatures and also symmetric and asymmetric encryption • X.509 certification functions, handling of certification paths and handling of revocation lists • Public Key Cryptography Standards (PKCS) • defined interfaces such as Authentication Framework (AF), Generic Security Services-API (GSS-API) • Privacy Enhanced Mail (PEM, MailTrusT) • commands for signing, validating, coding and decoding of files • commands for the operation of certification authorities and the interaction between certification authorities and certified users • all external data codings according to ASN.1 BER and DER • all functions take the millenium into account • safe storage of all security relevant information of the user in a so-called personal security environment (PSE) • optionally support for B1-chipcard readers and SmartCards (Deutsche Telekom, Schlumberger and GemPlus) is available - thus upgrading to SECUDE Security Grade High • optionally available is secure access to the public X.500 Directory for storage and production of certificates and revocation lists via LDAP • SECUDE SmartCard Technology
With the security infrastructure realised by SECUDE every participant is in possession of a private and a public key. The public key is certified by a certification authority (CA) and digitally signed. This procedure is comparable to the issuing of an ID card. With the user's local environment realised by SECUDE the keys are kept in a Personal Security Environment (PSE). The PSE is protected with a password or PIN (Personal Identification Number), which should be known only to the owner of the
247 PSE. The PSE is available in two versions, as software PSE or as SmartCard.
SECUDE contains the following APIs ([425]): • AF - Authentication Framework and Certification This module adds X.509 certification functionality to SECUDE. Both local (i.e. PSE-located) certificates and directory-located certificates can be addressed. Therefore SECUDE offers an integrated X.500 Directory User Agent or alternatively an AF-Database, which is an emulation of an X.500 Directory running on a file system. Additionally ASN.1 encoding and decoding routines and a lot more auxiliary functions are available. • CRYPT - cryptographic algorithms • GSS - Generic Security Services • PKCS - Public Key Cryptography Standard • PEM - Privacy Enhanced Mail Support This module converts functions, which realize the Internet Specifications RFC 1421 - 1424. The basic idea of PEM is to define document oriented message encipherment and authentication procedures for the protection of messages through the use of end-to-end cryptography between originator and recipient with no special processing requirements imposed on the message transfer system. This makes them transparent to the mail transfer systems and applicable for local security services, too. • SECURE - Personal Security Environment and Cryptography The SECURE API provides functions for the secure storage of data and basic cryptographic functions for the generation and verification of digital signatures, and encryption and decryption of data. All security relevant objects of a user are stored in a Personal Security Environment (PSE). The PSE typically contains the user's privat key, user certificate, public root key. Two PSE realizations are available either a smartcard or a software PSE. No higher level functionality, like certificate processing, is provided by this API. • SEC-SC - SmartCard Plug-in API • SCT - SmartCard Terminal API • S/MIME - Secure MIME
Implementation of X.509, ASN.1, PKCS, PEM. Uses commonly accepted algorithms like RSA, DES, DSS... ([426])
A5.6.3 Peer-to-Peer Trusted Library (Intel) http://sourceforge.net/projects/ptptl
The Peer-to-Peer Trusted Library is a software security toolkit tailored for the creation of P2P applications. The goal of this project is to spur open innovation in P2P security.
Intel，P2P セキュリティ API、「Peer-to-Peer Trusted Library」。 ピア認証，セキュアストレージ，暗号，電子署名などをサポート。 上記ページから Linux および Windows 版のパッケージを入手することができる。
Built on the open-source OpenSSL Toolkit, the P2P Trusted Library includes ([427]): • X.509 digital certificates • PKCS#12 (personal information exchange format) • RFC 1421 (privacy enhanced mail format) • PKCS#1 (RSA cryptography) • PKCS#5 (password-based cryptography) • Various standard symmetric encryption algorithms, including Blowfish • HTTP
248 The Trusted Library is portable to a wide variety of platforms including Win32 and Linux, with no licensing cost and minimal licensing restrictions.
A5.7 その他、標準、関連プロジェクトなど
A5.7.1 CMV Program (NIST) NIST (National Institute of Standards and Technology) の Computer Security Division では、暗号化の 標準の制定とこれら標準の認証プログラムをコーディネートしている。 Cryptographic Module Validation (CMV) プログラムは、暗号化モジュールと暗号化アルゴリズムの認証 テスト (validation testing) を提供している (参考資料[428])。
Cryptographic Modules • FIPS 140-1: Security Requirements for Cryptographic Modules, January 4, 1994. • FIPS 140-2: Security Requirements for Cryptographic Modules, May 25, 2001. Change Notice 1: 10/10/2001
A5.7.2 FPKI 正式名称は U.S. Federal PKI。以下、[429]より引用。 ・ A cross-governmental, ubiquitous, interoperable Public Key Infrastructure. ・ The development and use of applications which employ that PKI in support of Agency business processes.
参考情報として以下に FPKI に関連するサイトをあげておく。 • Federal PKI Technical Working Group, http://csrc.nist.gov/pki/twg/ • FPKI (Federal Public Key Infrastructure Steering Committee), http://www.cio.gov/fpkisc/business/index.htm • Federal PKI Steering Committee Website, http://www.cio.gov/fpkisc/
A5.7.3 ICE (International Cryptography Experiment) ICE イニシアチブは 1994 年初期に、国際的で相互運用可能な暗号セキュリティ解決策を促進することに 共通の興味を持つ、政府および業界団体による非公式の国際的なアライアンスとして設立された ([377])。 ICE のもう一つの側面には、DARPA ICE プロジェクトがあり、これは暗号ベースのセキュリティ コンポ ーネントを開発、デモするテクニカル プロジェクトであった。
ICE/CAPI ワークショップが 1995 年 9 月に第 2 回、1996 年 3 月に第 3 回、1996 年 12 月に第 4 回が開催 され、そのアジェンダが [377] に掲載されている。しかし、この後の情報はこのサイトに掲載されておら ず、この後に活動を行っていないようだ。
なお、これ以外の ICE の活動内容については、前述の A4.2 ICE で説明している。
A5.7.4 SESAME A Secure European System for Applications in a Multi-vendor Environment
249 https://www.cosic.esat.kuleuven.ac.be/sesame/
1) WHAT IS SESAME? SESAME (a Secure European System for Applications in a Multi-vendor Environment) is a European research and development project, part funded by the European Commission under its RACE programme. It is also the name of the technology that came out of that project.
The SESAME technology offers sophisticated single sign-on with added distributed access control features and cryptographic protection of interchanged data.
SESAME is a construction kit. It is a set of security infrastructure components for product developers. It provides the underlying bedrock upon which full managed single sign-on products can be built.
Examples of such products are ICL's Access Manager and Bull SA's Integrated System Management AccessMaster (ISM AccessMaster). Siemens (Software & Systems Engineering Ltd) is also using SESAME technology to improve its secure X.400 mail product set.
- http://emhain.wit.ie/~p98ac15/rep1/chap5.html
SESAME, standing for Secure European System for Applications in a Multi-vendor Environment, is a European research and development project, part funded by the European Commission under its RACE programme. It is also the name of the technology that came out of that project.
The SESAME project originated in the work of ECMA (the European Computer Manufacturer's Association) , who developed a set of standards (called ECMA-138, ECMA-206 and ECMA-219) which define the functionality and the protocols for a distributed security service in charge of authenticating and distributing access rights to human and application principals, along with supportive key distribution functions. In its first stage, the SESAME project was required to develop the ECMA work into a demonstrable implementation, in order to show that the ECMA architectural ideas and principles were feasible and practical, and was undertaken by Bull SA, ICL PLC and Siemens Nixdorf Informationssysteme AG (SNI) under part funding from the Commission of the European Communities (CEC). Eventually, through SESAME versions 2, 3 and 4, SESAME was developed into a set of security components for use in the construction of commercial security products
SESAME is, in essence, a construction kit. It can be used by product developers to produce single sign-on based security products in any environment (although it is mostly used in Unix-based systems). It is not a full security solution in itself, but can be used as the core upon which a security solution can be based.
SESAME supports role-based distributed access control, communication integrity and confidentiality through the use of encryption, and offers the means to ensure that access to services is policed to the appropriate level of security. SESAME also provides a single sign-on facility which enables the user to enter their username and password only once per session (normally at login time), which helps to increase security as the password is not being transferred over the network each time the user accesses a service. SESAME supports multiple domain operation with different security policies, and can be scaled to operate over very large networks through its use of public key technology.
SESAME is functionally similar to Kerberos, a distributed authentication technology developed as part of Project Athena by the Massachusetts Institute of Technology which, in its latest version (Kerberos V5) has been proposed as an Internet standard (rfc1510).
2) SESAME and the GSSGSS---APIAPI SESAME uses the widely accepted Generic Security Service Application Program Interface (GSS-API) Internet and X/Open standard as its interface to the application developer. This interface hides from its callers the details of the specific underlying security mechanism, leading to better application
250 portability. The GSS-API also completely separates the choice of security mechanism from choice of communications protocol. A GSS-API implementation is viable across virtually any communications method. GSS-API is also used as an interface by Kerberos and Netscape's Secure Socket Layer (SSL)
SESAME extends the GSS-API to support features needed to provide distributed access control.
A5.7.5 SPKI (Simple Public Key Infrastructure) IETF がインターネット ドラフトとして提案する IETF の Simple Public Key Infrastructure (spki) ワー キンググループ ([430]) がシグネチャ (signature) や他のフォーマットおよび鍵獲得プロトコル (key acquisition protocols)に関連する公開鍵証明書フォーマットのための、IETF がスポンサーとなるインター ネット標準を開発することを目的として活動しており、その成果として Simple Public Key Infrastructure、すなわち SPKI と呼ばれるフォーマットおよびプロトコルの標準を作成する。 SPKI は、IPSEC プロトコル、暗号化された E メールと WWW ドキュメント、ペイメント プロトコル (payment protocols)や、公開鍵証明書を利用する、あるいはそれらにアクセスする必要のある他のアプリ ケーションのような、幅広いインターネット アプリケーションをサポートするメカニズムを提供すること を意図している。 また、SPKI は将来、幅広いトラストモデル (trust models) をサポートすることを意図している。
SPKI (Simple Public Key Infrastructure) [431] SPKI は IPSEC、暗号化メールや Web 文書、支払いプロトコルなど公開鍵の証明書やこれにアクセスする 広範なインターネットのアプリケーションのためのフォーマットやプロトコルを定めた新しいスキームを 提供する。CyberCash の Carl Ellison が中心になって進めているもので、CA ベースの PKI が X.500/X.509 ベースの階層構造の名前空間と認証局を持つのに対して、SKPI は名前定義に SDSI をベース に用い、上位の認証局を必要としない証明書の提供するものとして、CA ベースの PKI とは対極をなすも のである。現在インターネットの Draft である。 http://www.ietf.org/html.charters/spki-charter.html
SKIP (Simple Key management for Internet Protocols) SKIP は ISAKMP/Oakley と同様に IP パケットレベルのネットワークのセキュリティの管理を行う。アプ リケーションはセキュアなチャンネルなどのセットアップなどの修正無しに暗号化などの利便を受ける。 SKIP は stateless プロトコルで、セットアップのオーバーヘッドがない、暗号化のゲートウェイの障害に 対してもリブートによって既存の接続の再ネゴシエーションの必要がない、IP ブロードキャストのような 単方向の応用も可能、スケーラブルなマルチキャストによる鍵配布ができる、ゲートウェイを複数設置し て耐障害性を可能にさせるなどの特徴がある。IETF の IPsec では SKIP ではなく、ISAKMP/Oakley を採 用することになった。 http://skip.incog.com/
SDSI (Simple Distributed Security Infrastructure) Rivest 等が提案している分散システムの公開鍵証明書の記述方法。名前空間をローカルなネーミングをベ ースとし、x.500 のような階層的なグローバルでユニークな構造をとらずに柔軟な多様な名前を用いるこ とができる。従って CA のような認証局を用いずに公開鍵の証明書の発行ができる。S-expression で記述 する形式をとり、豊富な表現が可能となる。SDSI の V1.0 が公開されており、v1.1 が SPKI のベースとし て用いられる。今後の方向は SDSI の V2 で SPKI とマージする方向が検討されている。 http://theory.lcs.mit.edu/~cis/sdsi.html
SPKI Certificate Documentation ([432]) The IETF SPKI documentation consists of two RFCs at this time:
RFC2692: Requirements giving the requirements gathered by the working group at the start of the process. ([433]) RFC2693: Theory giving the theory of authorization certificates, as opposed to name or ID certificates
251 that most people (e.g., X.509) discuss. This document points out some of the flawed assumptions in ID certificate theory and shows how SPKI's certificates (both authorization and ID) attempt to correct those flaws. ([434])
A5.7.6 SSL, TLS, PCT SSL の歴史 ([435])
SSL 1.0 バージョン 2 にすぐに置き換えられた。今では使われていない。 SSL 2.0 いくつかのセキュリティ問題を持っている。Netscape と Microsoft のブラウザ でまだサポートしているが、既に古くなっている。 PCT SSL 2.0 に対して Microsoft が提案した仕様。SSL 2.0 にいくつかの修正を施 したが、SSL 3.0 に取って代わられた。 SSL 3.0 SSL 2.0 を再設計することで問題を改修。また多くの機能を追加。 Netscape 3.0 以降と IE 3.0 以降でサポート。 TLS SSL 3.0 に基づいて開発中の IETF 標準。若干の改良がされている。
252
付録 6. ライブラリ、ツールキット、セキュリティ API 関連製品
ここでは、セキュリティ関連 API の洗い出しの過程でリストアップした、セキュリティ関連のライブラリ、 ツールキット、製品の一覧とその簡単な紹介をあげる。 なお、これら API の洗い出しの際に、次のような参考情報を参考にした。 • A6.1) FlexCrypto (ドゥイット) 雑誌 [436] • A6.2) Crypto++ (Wei Dai) ～ A6.7) NSS (Mozilla) リンク集 [437] の “Source Available Cryptographic Libraries” • A6.8) isasilk toolkit (IAIK) ～ A6.14) Cryptomathic リンク集 [437] の “NonSource Available Cryptographic Libraries” • A6.15) Oscar ～ A6.29) S/MIME Freeware Library (IMC) リンク集 [438] • A6.30) Personal Security Manager Architecture (Mozilla) ～ A6.32) CryptoKit (Algorithmic Research Ltd.) リンク集 [439]
A6.1) FlexCrypto (ドゥイット) http://www.do-it.co.jp/flexc/
FlexCrypto はドゥイットが開発した Java ベースの文字列暗号化ライブラリ。
A6.2) Crypto++ (Wei Dai) http://www.eskimo.com/~weidai/cryptlib.html
• License (4.1) Permission to use, copy, modify, and distribute this compilation for any purpose, including commercial applications, is hereby granted without fee, subject to minor restrictions. • C++ • Substantial docs, including a Manual and FAQ at SourceForge, and a windows "compiled html" help file for visual studio. • 488 Kbytes as crypto41.zip
A6.3) Cryptlib Encryption Toolkit (by Peter Gutmann) http://www.cryptlib.orion.co.nz/
• License: Free for non-commercial use, standard terms provided for commercial use. • C, with ActiveX and VB extensions available • Good and extensive documentation • 1656kb as cl30beta06.zip (Author suggests use of the beta version for all new development, as of July, 2001).
A6.4) BouncyCastle http://www.bouncycastle.org/
The Bouncy Castle Crypto APIs consist of the following:
253 • A lightweight cryptography API in Java. • A provider for the JCE and JCA. • A clean room implementation of the JCE 1.2.1. • Generators for Version 1 and Version 3 X.509 certificates. • A signed jar version suitable for JDK 1.4 (Beta) and the Sun JCE. • The lightweight API works with everything from the J2ME to the JDK 1.3 Java library, released under an open license
A6.5) borZoi (Dragongate Technologies Limited) http://dragongate-technologies.com/products.html 備考) リンク集では http://www1.kcn.ne.jp/~anthony/software/ だが、現在は上記の URL。
The borZoi library is an ECC library, designed for ease of use and a minimum risk of security problems due to incorrect use. Not as full featured as some others. GPL. Technical Details: The Public Key Algorithms in this library are based on those described in the IEEE P1363 standard and P1363a draft standard. The hash function used is SHA-1 and this may be changed to SHA-256 in a later release.
A6.6) MIRACL (Shamus Software Ltd) http://indigo.ie/~mscott/
MIRACL (Multiprecision Integer and Rational Arithmetic C/C++ Library).
MIRACL is a general purpose bignum library with a lot of crypto, including RSA, DH, DSA, ECC in several fields, and Lucas functions. Lots of examples, as well as support for AES and SHA. Non-commercial use is free, commercial use terms are included in the package.
A6.7) NSS (Mozilla) http://www.mozilla.org/projects/security/pki/nss/
Network Security Services (NSS).
From the fine folks at Mozilla, Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. MPL and GPL.
A6.8) isasilk toolkit (IAIK) http://jcewww.iaik.at/products/isasilk/
IAIK offers a family of libraries (IAIK-JCE for Java crypto, IAIK-iSaSiLk for SSL, and IAIK-S/MIME for S/Mime). Source is available at a standard price, which is better than no source, but not where they should be.
A6.9) PGPsdk (Network Associates, Inc.) http://www.pgp.com/products/sdk/default.asp
254 PGPsdk (PGP Software Developer Kit).
Network Associates, Inc. が提供する PGP ソフトウェア開発キット (PGPsdk) 。 PGP 技術をベースにした暗号化機能をアプリケーションに組み込むことができる。
A6.10) KeyTools, (Baltimore Technologies) Baltimore Technologies, http://www.baltimore.ie/ 日本サイト、http://www.baltimore.co.jp/
KeyTools Pro は基本ライブラリで、証明書ハンドリング、ディレクトリ サポート、証明書のリクエスト および取得のような、PKI の他の要素とのやり取りに必要な基本要素全てが含まれていますが、さらに広 範な e-セキュリティ メカニズムを装備し、エンド アプリケーションの機能性を高めます。それらの機能 例には、スマートカードのサポート、追加トランスポーター、OCSP、一元的なポリシー管理の実現、CRL Distribution Point (CRLDP)があります。
KeyTools Crypto は下位レベルのスタンドアロン開発コンポーネントで、セキュリティ システムにおいて 使用される共通暗号アルゴリズムおよび技術を実装することができます。KeyTools Crypto は、高度に最 適化された C ライブラリあるいは 100% pure Java ツールキットとして使用することができます。 • 次の技術をはじめとする高度な暗号化機能 RSA、DSA、Diffie-Hellman、DES、トリプル DES、RC2、RC4、SHA-1、MD2、MD5、RIPEMD-160、 Blum-Blum-Shub & FIPS 186 擬似乱数生成 • ASN.1 処理、Base 64、BER、DER コーダ • PKCS 標準準拠 • CESG 準拠擬似乱数ジェネレータ（C ライブラリのみ） • Intel ハードウェア ベース RNG のサポート（C ライブラリのみ） • 100％ pure Java で書かれた高度に最適化されたコード（Java ライブラリのみ） • PKCS #11 インターフェース（Java ライブラリのみ） KeyTools Crypto は、デジタル証明書ハンドリング、ディレクトリ アクセス、SSL、S/MIME、および PKCS #7 のような PKI 要素をサポートしない純粋な暗号モジュールとして設計されています。KeyTools Crypto はスタンドアロン モジュールであり、KeyTools Pro のスナップインコンポーネントとしては機能 しません。
A6.11) Certicom http://www.certicom.com/
Certicom has as large number of crypto and PKI toolkits available. ① WTLS Plus, http://www.certicom.com/products/wtls_plus/wtls_plus_feat.html The leading WAP security toolkit in the industry, WTLS Plus works with numerous WAP gateways and browsers. By incorporating ECC, WTLS Plus allows sensitive, Web-based commerce applications (such as banking and stock trades), to run on resource-constrained wireless devices with the same level of security available in a wired environment. ② SSL Plus, http://www.certicom.com/products/ssl_plus_prod.html Certicom's SSL Plus toolkits are used by companies such as AT&T, Intuit, Lotus, Oracle, Philips, Lucent Technologies, Sun and Sybase to easily deploy secure applications using public key cryptography and digital certificates ③ Security Builder, http://www.certicom.com/products/securitybuilder/securitybuilder_feat.html Security Builder is a standards-based cryptography toolkit that provides application developers with the sophisticated tools and flexibility needed to integrate encryption, digital signatures, and other security mechanisms into their applications. Security Builder is the only cryptography toolkit offering optimized Elliptic Curve Cryptography and
255 the RSA algorithm, complemented by a full suite of cryptographic functionality-effectively providing a single source for developers' cryptography needs. This enables customers to secure their future wireless needs while capitalizing on legacy infrastructures. Designed for use with a full range of computing platforms from servers to wireless devices. ④ Trustpoint toolkits, http://www.certicom.com/products/trustpoint_tool_prod.html and client offer developers a comprehensive line of tools for the addition of PKI functionality into wireless client and server applications. By offering flexible, standard-based PKI solutions, developers can build secure mobile commerce applications that interoperate with existing legacy PKI infrastructures to bridge the gap between wired and wireless platforms. Trustpoint/C Trustpoint/Java Trustpoint Client
A6.12) Phaos http://www.phaos.com/
Phaos has Java SSL implementations available. ① Phaos Crypto Phaos Crypto provides Java developers with a lightweight, extensible framework for integrating cryptography into Java applications. Furthermore, Phaos Crypto provides implementations of commonly-needed algorithms for encryption, key exchange, message digests, and random number generation. Phaos Crypto is written in 100% Java and compatible with all versions of Java, from JDK 1.1 through JDK 1.4. The Phaos Crypto Toolkit provides implementations of the RSA and DSA public key cryptosystems; message digests MD5 and SHA-1; and ciphers including the ARCFOUR (RC4) stream cipher algorithm, RFC 2268 (RC2) block cipher algorithm, DES, triple-DES and the Blowfish block cipher algorithm. ② Phaos Browser Scout; enables Java access to the certificates and keys stored in Web browsers, such as Microsoft Internet Explorer. ③ The Phaos Centuris PKI Platform provides developers with powerful, leading tools for developing PKI-enabled applications in just a few lines of code. The Centuris PKI Platform supports numerous open standards and specifications including PKIX from the Internet Engineering Task Force (IETF) and Public Key Cryptography Standards (PKCS). Centuris products also provide cross-platform support for Java, integration with enterprise databases and directories, and hardware support for maximum security of private keys and digital signatures. The Centuris PKI Platform provides a complete product line for building and managing PKI for enterprise and Internet applications. With Centuris products, you will achieve superior time-to-market and return on investment for your PKI application development efforts. ④ The Phaos J/CA Certification Toolkit is a complete CA (Certificate Authority) Toolkit for the Java platform. With the J/CA Toolkit, you can quickly create custom certificate servers for your application needs, issue and revoke certificates for use with Internet protocols such as SET or SSL, and manage your organization's Public Key Infrastructure (PKI). ⑤ Now, with the Phaos S/MIME Toolkit, Java developers can rapidly build S/MIME capabilities in their Java applications and applets. This means that developers of applications - from health care to EDI - can benefit from the "write once, run anywhere" portability of Java - while ensuring that messages delivered by email are secure and authentic. ⑥ Phaos SSLava the Standard Edition of the industry leading SSL toolkit comes with features such as: • client/server support for the SSL 3.0 protocol
256 • X.509 v3 certificate support • Comprehensive cryptography library that includes the RSA public-key algorithm and ARCFOUR/RC4 stream cipher, DES, 3DES, DSA, Diffie-Hellman • PKCS #5, #8 and #12 for private key security • PKCS #1 for RSA • HTTPS handlers for JSSE-style programming • Suitable for applets, client applications, and server applications • Debug logging • Medium footprint (approx. 200K)
A6.13) NTRU http://www.ntru.com/
NTRU offers a new public key cryptosystem, which is very fast, and targets the embedded market. I don't think that there is consensus on use of NTRU by cryptographers yet.
For more on specific implementations, download one of the following product briefs: • NTRU Mobile Security for the TI OMAP Platform • NTRU Embedded Java Solution • NTRU ANSI C Solution Available functions include: • Public key encryption/decryption • Key generation • Digital signatures • Signature verification • AES encrypt/decrypt (ECB and CBC) • SHA-1 hash • Create message digest • Pseudo-random number generator NTRU's security toolkit, NERI (NTRU Embedded Reference Implementation), is a low-footprint software toolkit designed for embedded implementations. A fast, small and easy-to-integrate security toolkit, NERI delivers reliable, highly secure cryptography, which can be quickly integrated into applications. NERI includes public key cryptography functions, symmetric key cryptography functions based on the new Rijndael Advanced Encryption Standard (AES), and tools for hashing and message digest creation. The result is a compact, high performance toolkit that meets the security needs of any application.
NTRU IS QUICKLY AND EASILY PORTED TO NUMEROUS PLATFORMS Versions available include: Windows (9X, 2000, NT)、 PocketPC Solaris、 Smart Card Linux、 VHDL PalmOS、 ARM EPOC、 TI C5xX DSP Java、 TI OMAP
A6.14) Cryptomathic http://www.cryptomathic.dk/
Cryptomathic in Denmark has a library which is claimed to be very fast. PRIMEINK Toolbox ① PrimeInk Conventional Cryptography
257 Application Examples: This toolbox provides security for: ・Personal file encryption ・Hard disk encryption ・Communication with predefined connections ・Communication tunnels, like in Virtual Private Networks (VPN) ・Ad-hoc file exchange Toolbox Elements PrimeInk Conventional Cryptography contains classic and modern symmetric key encryption algorithms as well as a wide range of secure hash functions. The functions are available through a PKCS #11 API as well as Cryptomathic’s specialized DIGSIG/CIPHER API. Alternatively, the toolbox is delivered for Java as a Cryptography Service Provider (CSP) conforming to the Java Cryptography Architecture (JCA). Language Availability PrimeInk Conventional Cryptography is available in Java and for a series of platforms including: Windows 95/98/NT/2000/CE, Linux, Mac OS, Palm OS, Sun Solaris, HP-UX, IBM AIX, OS/2, OS/400, and OS/390. Source code in Java or ANSI C can be delivered. ② PrimeInk for Client/Server Applications Application Examples: This toolbox provides security for: ・Communication with dynamic connections ・Remote network or system access ・Access control systems ・System Management applications Language Availability PrimeInk for Client/Server Applications is available in Java and for a series of platforms including: Windows 95/98/NT/2000/CE, Linux, Mac OS, Palm OS, Sun Solaris, HP-UX, IBM AIX, OS/2, OS/400 and OS/390. Source code in Java or ANSI C can be delivered. ③ PrimeInk Secure Mail for Applications ④ PrimeInk Premium for PKI Application Examples: This toolbox provides security for: ・Applications deployed outside a controlled environment ・Interoperable security solutions ・Access control in open environments ・Home banking ・Internet based groupware Language Availability PrimeInk Premium for PKI is available for a series of platforms including: Windows 95/98/NT/2000/CE, Linux, Mac OS, Palm OS, Sun Solaris, HP-UX, IBM AIX, OS/2, OS/400, and OS/390. Source code in ANSI C can be delivered. Technical Specifications Certificates: Symmetric key encryption: Key Exchange: X.509v3 (certificates & CRL) AES, DES, 3DES RSA, Diffe-Hellman
Secure messaging: Asymmetric key encryption: Utilities: S/MIME, PKCS#7 RSA, DSA ASN.1, MAP (Multiprecision Arithmetic Package)
Syntax formats: Hash functions: Programming interfaces, ANSI C: PKCS #1, 5, 8, 9, 10, 12, SPKAC SHA-1, MD5*, MDC2, MDC4, RIPEMD-160 PKCS #11, DIGSIG/CIPHER
Time stamping: PKIX-TST ⑤ PrimeInk for Web Applications ⑥ PrimeInk Internet Protocols
258 ⑦ PrimeInk for Mobile Applications ⑧ PrimeInk for B2B Communication
A6.15) Oscar http://oscar.dstc.qut.edu.au/
Oscar is a project aimed at designing and constructing a public key certification system from the ground up. The system will include all necessary components including, a Certificate Authority, Certificate repository and client interface. This will provide the infrastructure required to manage and administer a public key environment. The Oscar project aims to conform to existing and emerging standards such as the IETF PKIX, OSI X.509, and RSA PKCS standards. Oscar stands for Open Secure Certificate ARchitechture.
Generation, signing and verification of X.509 v3 certificates for RSA, Diffie-Hellman and DSA keys. Also supports Cross certificates for shortening certification paths. Signatures using RSA with SHA-1, RIPEMD-160, MD5 and MD2 and DSA with SHA-1. Also supports the HMAC algorithm, as well as the DES and SKIPJACK symmetric algorithms. Support for PKCS#7 Signatures, Netscape signed key challenges, and PKCS#10 Certificate Requests. PKIX compliant certification path processing many standard X.509 certificate and CRL extensions. Netscape certificate type extension for use with java code signing in Netscape, S/MIME email or as an SSL client certificate. Publishing and retrieving Certificates and CRLs in an LDAP directory. Storage of private keys in PKCS#8 format encrypted with DES keys using PKCS#5 password based encryption. In addition to a C++ library for development using the PKI, a number of utility programs are provided to publish and retrieve certificates from an LDAP directory; generate certificates, CRLs and key pairs; and sign and verify documents.
A6.16) CRYPTLB http://tirnanog.ls.fi.upm.es/Servicios/Software/ap_crypt/indice.html
Wei Dai's C++ Class Library of Cryptographic Primitives, Version 1.0, of 6/17/1995. Includes: MD5, SHS, DES, IDEA, WAKE, RC4, RC5, Blowfish, Diamond, Diamond Lite, Sapphire, Luby-Rackoff, MDC, various modes (CFB, CBC, OFB, counter), DH, RSA, DSA, ElGamal, BBS, gzip compression, Shamir's secret sharing scheme, Rabin's information dispersal scheme, and zero-knowledge prover and verifier for graph isomorphism. There are also various miscellaneous modules such as base 64 coding and 32-bit CRC
A6.17) BeeCrypt (Virtual Unlimited) http://www.virtualunlimited.com/products/beecrypt/
BeeCrypt is an open source cryptography library that contains highly optimized C and assembler implementations of many well-known algorithms including Blowfish, MD5, SHA-1, Diffie-Hellman, and ElGamal (full list). Unlike some other crypto libraries, BeeCrypt is not designed to solve one specific problem, like file encryption, but to be a general purpose toolkit which can be used in a variety of applications. There are also no patent or royalty issues associated with BeeCrypt, and it is released under the GNU LGPL license (read more), which means it can used for free in both open source and closed source commercial projects.
BeeCrypt for Java In addition to the C and assembler version of BeeCrypt, a pure Java version of BeeCrypt is also
259 available. BeeCrypt for Java is a JCE 1.2 compatible Cryptographic Service Provider (CSP) and can be used with BeeJCE, our version of Sun's Java Cryptography Extensions. Because we are a Dutch company, you can use BeeCrypt for Java and BeeJCE to build Java products that are freely exportable worldwide.
What does it contain? The BeeCrypt library currently includes: Entropy sources for initializing pseudo-random generators Pseudo-random generators: FIPS-186, Mersenne Twister Block ciphers: Blowfish Hash functions: MD5, SHA-1, SHA-256 Keyed hash functions: MD5/HMAC, SHA-1/HMAC, SHA-256/HMAC Multi-precision integer library, with assembler-optimized routines Probabilistic primality testing, with optimized small prime trial division Discrete logarithm parameter generation over a prime field Diffie-Hellman key agreement DHAES encryption scheme ElGamal signature scheme (two variants) Basic RSA primitives and key pair generation Planned for future versions...
Manual http://www.virtualunlimited.com/support/beecrypt/apidoc/
A6.18) Catacomb http://www.excessus.demon.co.uk/misc-hacks/#catacomb
A library of cryptographic primitives. Currently, there are a few block ciphers and hash functions, together with generic modes for building more interesting constructions from them. There's also what used to be a simple key management system, a multiprecision maths library, some public key algorithms and various useful tools.
A6.19) cryptlib http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ cryptlib is a powerful security toolkit which allows even inexperienced crypto programmers to easily add encryption and authentication services to their software. The high-level interface provides anyone with the ability to add strong security capabilities to an application in as little as half an hour, without needing to know any of the low-level details which make the encryption or authentication work. Because of this, cryptlib dramatically reduces the cost involved in adding security to new or existing applications. cryptlib provides a transparent and consistent interface to a number of widely-used security services and algorithms which are accessed through a straightforward, standardized interface with parameters such as the algorithm and key size being selectable by the user. Included as core components are implementations of the most popular encryption and authentication algorithms, Blowfish, CAST, DES, triple DES, IDEA, RC2, RC4, RC5, Safer, Safer-SK, and Skipjack conventional encryption, MD2, MD4, MD5, RIPEMD-160 and SHA hash algorithms, HMAC-MD5, HMAC-SHA, HMAC-RIPEMD-160, and MDC-2 MAC algorithms, and Diffie-Hellman, DSA, Elgamal, and RSA public-key encryption.
On top of the basic encryption services, cryptlib provides an extensive range of high-level capabilities including full X.509 certificate handling with support for all X.509v3 and IETF PKIX certificate features as well as support for SET, Microsoft AuthentiCode, S/MIME, and SSL client and server certificates, handling of certification requests and CRL's including automated checking of certificates against CRL's, creation and processing of PKCS #7 certificate chains, and a full range of certification
260 authority (CA) functions. Alongside the certificate handling, cryptlib provides a sophisticated key database interface which allows the use of a wide range of key database types ranging from PKCS #15 key files and PGP keyrings through to commercial-grade RDBMS's and LDAP directories with optional SSL protection. To complement its key management capabilities, cryptlib provides a complete S/MIME implementation with full-strength encryption, allowing email, files, and EDI transactions to be authenticated with digital signatures and encrypted in an industry-standard format.
In addition to its built-in capabilities, cryptlib can make use of the crypto capabilities of a variety of external crypto devices such as hardware crypto accelerators, Fortezza cards, PKCS #11 devices, and crypto smart cards. The crypto device interface also provides a convenient general-purpose plug-in capability for adding new functionality which will be automatically used by cryptlib. cryptlib is supplied as source code for Unix (static and shared libraries), DOS, Windows 3.x, Windows 95/98, Windows NT/2000, OS/2, BeOS, Macintosh, and the Tandem environment, and also as 16- and 32-bit Windows DLL's. cryptlib is also available as an ActiveX control for Windows, and adaptations exist for VM/CMS and MVS mainframe environments, see the cryptlib FAQ for more information on the mainframe versions.
Thanks to Sami Tolvanen and CAI there is a cryptlib ActiveX control available which can be used with Visual Basic and other languages. This location also contains a compiled Windows binary of the cryptlib DLL for people who don't have Visual C++, and the cryptlib user interface components which provide a key/certificate generation wizard and certificate viewer. There is also a VB interface for cryptlib itself (which doesn't use the ActiveX control) available.
A6.20) CTC http://www.bifroest.demon.co.uk/ctc/
CTC is a collection freeware PGP-interoperable encryption software package developed by Ian Miller and Mr. Tines. CTC does not stand for anything; it is Rot13 ("PGP").
① CTClib is a PGP-interoperable encryption software library developed by Ian Miller and Mr. Tines. CTClib and the applications built upon it are a PGP 2.6 and 5 compatible encryption system, offering not only compatibility with PGP, but a selection of alternative recognized strong encryption algorithms (128-bit Blowfish, Square, s3'DES, Biham's key-dependent DES, TEA & 3Way for conventional encryption, in ECB, CBC, OFB as well as the standard CFB mode, Elliptic curve on GF (2^255) for public key), in addition to those supported by PGP5 (triple DES, CAST5, SHA1, and Diffie-Hellman).
② CTCjava Blowfish, DES, TripleDES, CAST5, IDEA, Square, 3-Way, MD5, SHA-1 and SHA-0, SAFER and TEA.
A6.21) Emacs Cryptographic Library and Tools http://web.mit.edu/thouis/www/ecrypto.html
Ecrypto2.0.tgz (29436 bytes) - an emacs crypto library. includes code for IDEA, Blowfish, SHA-1, MD5, RC16 (RC4 extension), an initial implementation of DES, and a few related toys. (Note: sometimes the caching on this server seems to go haywire. if you end up with fewer than 29436 bytes, please mail me and I’ll kick it until it works again. or check at this link.)
261 A6.22) FWTK (FWTK.ORG) http://www.fwtk.org/main.html
The FireWall ToolKit (FWTK) is a set of proxies which you can use to build your own firewall.
A6.23) C++ PKI toolkit (Globera) http://www.globera.com/certify.php3 globera/certify: C++ PKI toolkit (certificates, smart cards).
Certify is a C++ library that removes economic and technical headaches from the development of PKI-enabled applications. Certify is entirely free for non-commercial use, and there are no run-time royalties for commercial use. On the other hand, the library comes with all the flexibility that you would expect from a mainstream PKI library. The following are a few examples to illustrate our point: • Straightforward usage and creation of digital certificates (RFC2459) and certificate requests (RFC2511, PKCS#10) • BER decoding and DER encoding of arbitrary ASN.1 objects • Transparent manipulation of PKCS#11 cryptographic tokens • Full integration with the public domain Crypto++ library
A6.24) JCSI (Wedgetail) http://www.wedgetail.com/jcsi/index.html
JCSI - Java Crypto and Security Implementation
JCSI features • A clean-room JCE framework implementation which interoperates with Sun's JCE 1.2 (domestic US version) • A Crypto Provider for JCA/JCE implementing the JCA/JCE engine classes • A Public Key Infrastructure (PKI) library including CertificateFactory Provider for X.509 v3 certificates & v2 CRLs • A PKCS#12-based KeyStore Provider interoperating with Netscape and Microsoft IE • An API for PKCS#10 certification requests • An API for creating X.509 certificates and CRLs, and publishing to an LDAP repository • An API for PKCS#8 and SSLeay-style private key protection • An SSL/TLS (Transport Layer Security) library implementing JSSE supporting RSA and Diffie-Hellman, session cache management and CRLs • A Cryptographic Message Syntax (CMS) library supporting data streaming • An S/MIME v3 library compatible with JavaMail 1.2 and interoperable with popular S/MIME clients, including Netscape Messenger and Microsoft Outlook and Microsoft Outlook Express • A Kerberos 5 library including an API for communicating with a KDC (e.g. win2K) and GSSAPI (RFC 2853) for application-level messaging
A6.25) JSSL http://www.vonnieda.org/jSSL/
SSL implementation in Java.
EspreSSL (used to be jSSL) is basically dead because of a few different things. • Sun has released JSSE which is a free, pure Java implementation of SSL. It remains to be seen if this will be free for commercial use. I don't see how they can unless RSA suddenly became much
262 nicer about royalties. • Another project called PureTLS was released a while back which meets several of the goals of the EspreSSL project. This guy also seems to have more balls than I do about releasing export controlled software on the net without verification. • I got tired of worrying about export control laws and patent problems with RSA. EspreSSL was in the right all the way, but if someone felt like making my life miserable they probably could have since I don't like long court battles. I felt the best way to deal with this was leave the code and binaries down, but this does not facilitate Open Source development.
The main goal of the project was to provide the world with a free, open and pure Java SSL toolkit. Others have done this so I lost interest in the project since the goal was met (albeit by someone else). With that in mind, with the expiration of the RSA patent coming up in September and new laws about export from the US being forged as we speak, the project could come back to life. If this were to happen, I would be refocusing on making EspreSSL a 100% open provider of JSSE services since Sun was nice enough to make an API for us. I will post this message to the web site so other people can know what is going on.
A6.26) M2Crypto (by NG Pheng Siong) http://www.post1.com/home/ngps/
Python crypto toolkit.
M2Crypto = Python + OpenSSL + SWIG M2Crypto makes available to the Python programmer: • RSA, DSA, DH, HMACs, message digests, symmetric ciphers • SSL functionality to implement clients and servers • HTTPS extensions to Python's httplib, urllib, and xmlrpclib • S/MIME v2 M2Crypto works with the following: • Python 1.5.2, 2.0 and 2.1 • OpenSSL 0.9.6 and above • SWIG 1.3.6 • Read what others say about M2Crypto.
A6.27) Package Acme.Crypto http://www.acme.com/java/software/Package-Acme.Crypto.html package Acme.Crypto Various Java crypto classes.
A6.28) SCEZ http://www.franken.de/crypt/scez.html
SCEZ is Smart Card Library (Smart card means only processor card, not every chip card.) with following aims: • Easy to use. • Free. • Portable. • Simple. • Small. • Transparent, i.e. you know what it does.
263 • Useful. It is fully compliant to the aim "Free". The other points need more or less work done. SCEZ is distributed under a BSD style license. The archive has currently about 300kB gziped.
A6.29) S/MIME Freeware Library (IMC) http://www.imc.org/imc-sfl/index.html
S/MIME Freeware Library (SFL).
Getronics Government Solutions http://www.getronicsgov.com/hot/sfl_home.htm
以下、資料[440]のプレゼン資料から図を引用。
264
A6.30) Personal Security Manager Architecture (Mozilla) http://mozilla.org/projects/security/pki/psm/arch.html
Personal Security Manager (PSM) 1.x is a client-independent desktop security module. It performs PKI operations on behalf of desktop client applications, including certificate and key management, SSL, S/MIME, cryptographic token support, and centralized administration.
A6.31) 4758 Coprocessor Toolkit (IBM) http://www.alphaworks.ibm.com/aw.nsf/techmain/26654248BDF3CA7B8825687200035C6F?OpenDoc ument
4758 Coprocessor Toolkit is a software development kit (SDK) for creating secure coprocessor applications. The 4758 Coprocessor is itself a tamper-sensing and -responding secure coprocessor, along with its own internal operating system (CP/Q), secure software configuration, bootstrap features, support software, and development tools. This programmable cryptographic PCI card also contains a general-purpose CPU, advanced encryption hardware, various memory and data storage options (RAM, EEPROM, battery-backed RAM), a true hardware random number generator, and a secure time-of-day clock. All of these features make the 4758 Coprocessor unique among secure coprocessors.
The 4758 Coprocessor was the first device ever to earn the highest possible certification for commercial security awarded by the US Federal government. It was validated at Federal Information Processing Standard (FIPS) 140-1 Level 4 overall (certificate #35). Subsequent versions and embedded software support have also undergone third-party security evaluations.
A6.32) CryptoKit (Algorithmic Research Ltd.) http://www.arx.com/products/cryptokit.html
CryptoKit is a powerful set of development tools that enable convenient integration of
265 cryptographic-strength data security into any third-party application. CryptoKit functionality can be easily incorporated even by developers with no prior cryptographic experience. The CryptoKit toolkit supports the industry-wide MS CAPI and PKCS#11 standards in addition to AR's High-Level API. An integral part of Algorithmic Research's Security Architecture, CryptoKit serves as the underlying technology for all AR products.
A6.33) System-Security-API version 2.10 for Windows 95,98 http://www.shetef.com/ssapi2.html
The System-Security-API provides an Application Programmable Interface which allows an application developer to protect resources and file access on a machine which runs Microsoft Windows 95,98 operating system. Three levels of protection, based on file access. One programmatically can Hide specific files or folders (Hide), prevent all access to the files (No Access), allow only Read Only access. Includes a sample application with source. Please check if you are using the last version of the product. The last version of the product can be downloaded from out Web Site at: http://www.shetef.com
なお、このパッケージは以下の URL などでも配布している。 http://www.programfiles.com/index.asp?ID=9015 http://www.32bit.com/software/listings/Utilities/Special/_540P/734/ http://www.softlookup.com/dis7871.html
A6.34) Veridicom Software Development Kit http://www.veridicom.com/products/sdk.htm
266
付録 7. 用語
Abstract Syntax Notation One (ASN.1) シリアル伝送 (serial transmission) のために抽象オブジェクトを規定するのに使う方法。
BAPI ソフトウェア・アプリケーションとバイオメトリック デバイスが通信する場合のアプリケーションインタ フェースを定義しており、I/O Software 社がバイオメトリックスのハードウェア、ソフトウェアベンダー に声をかけて組織したワーキンググループによって提案されている。
BioAPI Compaq Computer 社、IBM 社、Identicator Technology 社、Microsoft 社、Miros 社、Novell 社が推進 団体となって組織された BioAPI コンソーシアムで開発されたバイオメトリック技術のための標準 API 仕 様である。
BLOB Binary Large OBject、バイナリ ラージ オブジェクト。 データベースシステムで定義されるデータ型の一つ。画像や音声などのバイナリデータを格納できる。
CAPICOM アプリケーションにデジタル署名 (digital signing) および暗号化 (cryptography) を用意に統合できる、 Microsoft Visual Basic, Visual Basic Script, ASP, C++ で利用可能なインタフェースで、Microsoft CryptoAPI に対する COM インタフェースを提供する ActiveX である。
Certificate Store 一般には証明書 (certificates)、CRL (certificate revocation list)、CTL (certificate trust list) が永続的に格納される記憶装置を指す。しかし、certificate store を単独でメモリに作成、オープンする際 には永続的な記憶装置に格納する必要はない。Certificate Store は CryptoAPI の証明機能の中心的な役割 を果たす。
CryptoAPI Microsoft が策定する API で、この API を利用することによって Win32 ベースのアプリケーションにイン ターネット コマースなどに必要な暗号化/復号化、暗号キー格納/交換、デジタル署名、デジタル認証など のセキュリティ機能を容易に追加することができる。
CryptoSPI CSP で利用されるシステム プログラム インタフェース。
267 CSP (Cryptographic Service Provider) 認証 (authentication)、コード化 (encoding)、暗号化 (encryption) のために、実際の暗号アルゴリズム を実行する独立したソフトウェア モジュール。
CVE (Common Vulnerabilities and Exposures) CVE は脆弱性 (Vulnerability) および 露出(Exposure)に関する情報を共有するために、これらの名前を 標準化して蓄積する辞書のことである。CVE を採用、推進する組織として、Axent、CERT、CyberSafe Corporation、ISS、Network Associates Inc.、Symantec などがある。 http://www.cve.mitre.org/
DISA (Defense Information Security Administration) 防衛情報保全当局。交戦部隊に情報システム支援を供給する責務を託されている軍事組織。
DISA (Defense Information Systems Agency) 目的 : 平和時・戦時を問わず、米国国防関連部門で使用する C41 (指揮・統制・通信・コンピュータおよび情報) 関連システム全般の計画・設計・開発・プログラム管理・調達・実装・および運用と保守全般を担当し、 システムの効率的な運用を支援すること 組織 : • DISA は国防省の中で情報技術を担当する部局であるとともに、防衛情報支援機関 (DII: Defense Information Infrastructure) 中枢部門の中央指揮部局である。最近サービス業務効率改善のため、組 織構成を指揮スタッフ・組織スタッフおよび地方ライン機関の 3 部門に改編した。 • 指揮スタッフ部門には、副指揮官 (DV)、スタッフ長、情報主任、検査官、共同委員会事務局、役員 グループ、検査官グループ、均等機会雇用・文化関連オフィス、公共部門、プロトコル部門、NSA 窓 口、規制/一般評議会、小規模/不利益ビジネス相談所および議会部門を含まれる。 ・組織スタッフ部門には、D1 (人事本部長)、D2 (C4 および知的プログラム担当部長)、D3 (オペレー ション担当部長)、D4 (ロジスティックスおよび調達担当部長)、D5 (戦略プランおよび政策担当部長)、 D6 (エンジニアリングおよび相互運用性担当部長)、D7 (ジョイント要求分析および統合)、D8 (C41 モ デリング、シミュレーションおよび評価担当部長) • 地方ライン機関には、WESTHEM,DITCO、JITC、JIEO、ヨーロッパ支部、太平洋支部 および STRATCOM、TRANSCOM、SOUTHCOM、CENT/SOCOM、ACOM、SPACECOM などの フィ ールドオフィスを設置している。 • その他、米国大統領オフィスを支援する NCS、ホワイトハウスの通信機関である WHCA も設置し ている。 活動状況 : ① DISA の活動目的を達成するため、以下の部門に分かれて活動を行っている。 • Global Command and Control Systems (GCCS): C41 の単一システムである自動情報システム の開発を行う。 • Defense Information System (DISN): DoD の指示に基づき、戦闘機等へ情報システムの受け渡 し支援を行う。 • Defense Message System (DMS): DoD 内でのメッセージングサービスやセキュリティのレベル を下げずに、維持費を削減する活動を行う。 • Global Combat Support System (GCSS): 戦闘支援システム技術の改良を促進するための活動を 行う。 • Defense Information (DII COE): Defense Information Infrastructure (DII) について、各ワーキ ンググループを設置して活動を行う。
268 • Information Security (INFOSEC): INFOSEC Program Management Office (IPMO) を設置し て、DII システムのための情報システムセキュリティプログラムの開発を行う。 ② INFOSEC Training Facility (ITF) 内でのトレーニング講座の提供を行う。 ③ 西暦 2000 年問題についての活動を行う。
DII COE (Defense Information Infrastructure Common Operating Environment) 防衛情報基盤共通運営環境。
DoD (Department of Defense) 国防総省。
EMM (Elective Module Manager) CDSA に新しいセキュリティ サービスを追加するための機構。HRS は CDSA フレームワークの EMM の 実例。
Enhanced Key Usage (EKU) 証明書拡張 (certificate extension) と証明書の拡張プロパティ値 (certificate extended property value) の両方。EKU は証明書が妥当かどうか確かめる方法を規定する。
Globus Globus は、広域計算システムのためのツールキットであり、通信ライブラリやディレクトリサービスやリ ソース管理機構など、比較的低位の機構を提供している。ユーザは Globus の上に実際に使用するシステム を構築する。 Globus は、認証機構として GSI(Globus Security Infrastructure)を提供している。 GSI には、各サイト のローカルセキュリティポリシは変更しない、子プロセスへのアクセス権の伝搬が可能、といった特徴が ある。Globus にはグローバルな単一のユーザ名空間があり、これをサイトローカルなユーザ名空間にマッ プする。サイト内ではサイトローカルのセキュリティ ポリシに従ってアクセスコントロールが行われる。 ローカル空間へのマッピングの際に、 Globus が運用する発行機関による証明書に基づいた認証が行われ る。
GOTS (Government-Off-The-Shelf) 政府調達製品?
GSS-API (Generic Security Service Application Programming Interface) さまざまな異なったセキュリティメカニズムによって供給されるサービスへの汎用的なインタフェースを 提供するもので Internet Engineering Task Force (IETF) により開発され Open Group で採用されてい る。
HA-API 個人の認証や識別のためのバイオメトリック技術を組み込むソフトウェア・アプリケーションのインタフ ェースを定めたもの。もともと National Registry 社が米国防省の依頼により開発した仕様であるが、普 及のために一般公開されている。
269 ICE ICE (International Cryptography Experiment) は、個人、業界、政府によるインフォーマルな国際的ア ライアンスである。
JNDI (Java Naming and Directory Interface) 企業内の複数のネーミングおよびディレクトリサービスへの統一したインタフェースを提供するパッケー ジ。
KCS (Public-Key Cryptography Standards) Apple や Microsoft、DEC、Lotus、Sun、MIT 等との 非公式コンソーシアムによる協同作業の結果として RSA Laboratories が纏めた、公開鍵暗号に関係する各 種規格のセットである。
Kerberos Kerberos は マサチューセッツ工科大学 (MIT: Massachusetts Institute of Technology) のアテナプロジ ェクト (Project Athena) で開発されているオープンネットワークシステムのための認証システム。 Kerberos は認証方式に、1978 年に R. Needham と M. Schroeder によって提唱された鍵配布モデルに 基づく「信頼のおける第三者機関による認証」 ("Trusted Third Party Authentication") の概念を採用し、 Miller と C. Neuman により設計された。
MIB (Management Information Base) MIB バージョン 1 はおおまかにいって SNMP バージョン 1 に対応し、RFC1155 で文書化されている。 MIB-II は最も広く実装された MIB で、RFC 1213 で文書化されている。RFC 1902 は MIB バージョン 2 の構造を論じている。IANA は ISI で大規模の MIB リポジトリを維持している。 http://www.freesoft.org/CIE/Topics/107.htm MIB は Simple Network Management Protocol (SNMP)を用いて管理されるネットワーク オブジェクト のセットを公式に規定したものである。MIB のフォーマットは SNMP の一部として定義されている(他の MIB の全てはこの基本 MIB の拡張にあたる)。MIB-I は初期の MIB 定義に該当し、MIB-II は現在の定 義に相当する。SNMPv2 は MIB-II を含み、幾つかの新しいオブジェクトを追加している。 There are MIBs (or more accurately, MIB extensions) for each set of related network entities that can be managed. For example, there are MIB definitions specified in the form of Requests for Comments (RFCs) for AppleTalk, domain name system (DNS), Fiber Distributed-Data Interface, and RS-232C network objects. Product developers can create and register new MIB extensions. Companies that have created MIB extensions for their sets of products include Cisco, Fore, IBM, Novell, QMS, and Onramp. http://searchsystemsmanagement.techtarget.com/sDefinition/0,,sid20_gci214095,00.html
MISSI (Multilevel Information System Security Initiative) MISSI とは Multilevel Information System Security Initiative の略で、米国政府のためにデータおよび ネットワークのセキュリティを開発、調達する NSA のプログラムのことである。
MSP (Messaging Security Protocol) 電子メールなどのインターネット メッセージを保護するための S/MIME や PEM などのアプリケーショ ン レベルの保護プロトコルの一つ。暗号化されたメッセージ内容を得るのに暗号化されていないメッセー
270 ジをカプセル化するという、一般的なメッセージプロトコルを用いている。また、DoD のような連邦政府 機関によって利用されているセキュリティ プロトコルである。
NSA (National Security Agency) 国家安全保障局。この機関は、海外電子信号を利用し、合衆国国家安全保障に致命的な電子情報を保護す る任務を託されている。
Object identifier (OID) ASN.1 により規定される抽象オブジェクトのための Object identifier (ASN.1) 。 Object identifier はアルゴリズムや属性型のようなオブジェクトを識別する整数列である。
OPSEC (Open Platform Secure Enterprise) オープンな企業セキュリティプラットフォームを確立するためにチェックポイントが提唱している仕様。 同社が公開している API である CVP，UFP，SAMP はじめ，LDAP，SNMP，ODBC といった業界標準 のプロトコルと高性能スクリプト言語によって，サードパーティは OPSEC フレームワークに沿ったアプ リケーションを組むことができる。
PAC (Privilege Attribute Certificate) PAC と呼ばれるアクセス制御のための情報。ECMA および ISO/ITU-T 標準に準拠するためのアクセス 管理証明書 (Access Control Certificate) の特殊な形式である。
PCT (Private Communications Technology) PCT はマイクロソフト社が提唱するインターネット上でプライバシーを保護してクライアント/サーバア プリケーションの認証を行い、通信上の盗聴を防止するために考えられたセキュリティプロトコルであり、 Netscape Communications 社の SSL (Secure Socket Layer) プロトコルに改良を加えてセキュリティ機 能の強化とパフォーマンス向上させたプロトコルである。 http://www.net.intap.or.jp/oiia/cont1/p0302.html{0recid=10419.html 標準化動向 : PCT プロトコルは IETF(Internet Engineering Task Force)で標準化が検討されている。 1995 年 9月 最初のドラフトが提出された。 1995 年 10 月 改良されたドラフトが提出された。
PFX (Personal Information Exchange) - PKCS#12 PFX または PKCS #12 (Personal Information Exchange) と呼ばれる形式を使うと、証明書と証明書に 対応する秘密キーを 1 つのコンピュータから別のコンピュータに、あるいはコンピュータからリムーバブ ル メディアに転送できる。PKCS #12 は、証明書と証明書に関連付けられた秘密キーの転送またはバッ クアップと復元に適した業界標準形式。この操作は、同じベンダーの製品間でも、異なるベンダーの製品 間でも行うことができる。PKCS #12 形式を使うには、暗号化サービス プロバイダ (CSP) が証明書とキ ーをエクスポート可能として認識しなければならない。証明書が Windows 2000 証明機関によって発行さ れている場合、その証明書の秘密キーは、次のどちらかの条件が満たされている場合にのみエクスポート できまる。
271 PIM (Protocol Independent Multicast) 既存の IP ネットワークにマルチキャスト ルーティングを追加するアーキテクチャ。IETF PIM ワーキ ンググループで検討されている標準である。
PKI (Public Key Infrastructure) (E コマース、銀行、正規の取引のような) セキュアな E ビジネスや(医療、年金・社会保障などの政府業務) セキュアな E 福利厚生といった分野に適用される、世界規模で適用可能な公開鍵暗号を用いたインフラの こと。 近年進展著しい電子商取引や、 各国・地域で構築が進みつつある電子政府のサービスに欠かせない公開鍵 基盤と呼ばれる電子認証基盤の一つです。
PMI (Privilege Management Infrastructure、権限管理基盤) ユーザの権限を制御するためのインフラ。
PStore (Protected Information Store) ネットワーク ユーザに関する個人情報およびセキュリティ情報を安全に格納するための WindowsNT の 技術。証明書、クレジットカード情報、個人情報などをその格納対象とする。
備考) 資料[1]によると、PFX プロトコルと Authenticode で使われているデジタル署名技術が W3C にド ラフトとして提案された、と書かれている。しかし、IPA のサイトに掲載された「X.509 電子証明書の問 題調査」、「SSL と S/MIME で、電子証明書を引き継ぐことの技術的可能性について」 http://www.ipa.go.jp/security/fy10/contents/over-all/02/24.html によると、PKCS#12 が公開される以前に Microsoft PFX0.020 という規格が存在していた。 PFX (Personal Exchange Syntax and Protocol Standard) は秘密鍵や公開鍵証明書などに限らず、クレ ジット番号などの個人情報を格納するための規格である。 <略> その後 PFX をベースに PKCS#12 の標準化が行われた。相互運用性を考慮して Netscape Communicator 4.04 以降及び Internet Explorer 4.0 以降はインポートする場合に限り PFX がサポ ートされている。これらのバージョンにおいてはエクスポートする場合に PFX は利用されず PKCS#12 が用いられる。 とある。また、「Authenticode が標準化された」という情報を入手することはできなかった。
SASL (Simple Authentication and Security Layer) は、クライアント サーバ間のデータ交換の場合において、認証と(オプションとして)引き続き行われるコ ミュケーションで達成されるセキュリティレイヤーの確立のために用いられるチャレンジ-レスポンス プ ロトコルを規定する。これは、LDAPv3 または IMAPv4 のようなコネクション-ベースのプロトコルで用 いられる。また、SASL の標準は RFC2222 で規定されている。
SESAME (a Secure European System for Applications in a Multi-vendor Environment) ヨーロッパの官学共同プロジェクトで、Kerberos5 の認証もサポートするというシステム。
272 SET (Secure Electronic Transaction) インターネットを含むオンライン ネットワークの任意のタイプで利用される支払い用カードに関連する 組織を認証するための技術を利用するために設計された仕様のこと。SET は情報の機密性の維持、メッセ ージ完全性の確証、トランザクションに関わる組織の認証に焦点を当てている。
SPKM (Simple Public Key GSS-API Mechanism) SPKM メカニズムは、PKI を用いたオンライン分散アプリケーション環境において、認証 (authentication)、鍵確立 (key establishment)、データ完全性 (data integrity)、データ機密性 (data confidentiality) を提供する (Source: RFC 2025)。 秘密鍵暗号方式をよる認証システムである Kerberos は GSS-API を用いて実装が行われているのに対し SPKM は公開鍵方式に基づいた認証システムであり、この API で認証の実装が行われる。 Kerberos の方式では相互の認証にタイムスタンプを用いてセッション鍵の有効性をチェックする必要が あるために鍵を利用するユーザは時間が一致することを前提とするのに対し、SPKM は暗号化されたタイ ムスタンプを用いなくても一方又は相互認証が可能となる。 Kerberos と SPKM はデータフォーマットとプロシージャは同じ形式なので、Kerberos が既に利用されて いる環境における実装は簡単にできる。又、SPKM は特定の暗号アルゴリズムに制限されず、今後新しい アルゴリズムにも対応できるように Algorithm 識別子を使用していることも特徴である。SPKM の鍵管理 は認証のフレームワークである X.509 や暗号メールの規格である PEM (Private Enhanced Mail) と互換 可能となっている。
SSL (Secure Socket Layer) SSL はインターネット上の盗聴 (eavesdropping)、改ざん (tampering)、メッセージ偽造 (forgery) を防 ぐためのセキュリティ プロトコルである。SSL サービスは 2 つの通信端末の間でセキュアなセッション を確立する。基本的な機能は証明ベース (certificate-base) の認証、エンドツーエンドのデータ完全性 (end-to-end data integrity)、オプションのデータ プライバシー (optional data privacy) である。SSL は IETF に TLS のためのインターネット ドラフトとして提案されている。 また、SSL は Web 上に暗号機能を実装するために広く使われるプロトコルであり、SSL 3.0 は Netscape 4.x および 6、Internet Explorer 4.x および 5.x、AOL、Opera など多くのブラウザで利用されている。
SVN (Secure Virtual Network) Check Point の Secure Virtual Network (SVN) は Check Point 全製品がこの上に構築されているアーキ テクチャのことである。 SVN はユーザ、インターネット、イントラネット、エクストラネット環境に渡るネットワーク、システム、 アプリケーション、セキュアでシームレスな接続性を提供する。 http://www.checkpoint.com/svn2/index.html http://www.checkpoint.com/svn/index.html
TLS (Transport Layer Security) SSL は Netscape が開発し IETF が標準化したが、現在、IETF は SSL を TLS と名前を変えている。TLS はちょうど SSL version 3.1 にあたる。
共通鍵暗号 (Secret Key Cryptography) 通信する双方のみが秘密鍵 (secret key) を共有し、その秘密鍵を使ってお互いの認証、および暗号通信を 行う方式。尚、通信する双方が別手段を使い、予め秘密鍵を共有する必要がある ([441])。
273 また、秘密鍵暗号、対称暗号方式 (Symmetric Cryptography) とも呼ばれる。
公開鍵暗号 (Public Key Cryptography) 最初に私有鍵 (private key) と公開鍵 (public key) の鍵のペアを生成し、通信の相手に公開鍵のみを渡す。 この方式は、公開鍵で暗号化したものはペアで生成された私有鍵でしか復号化できないと言う数学的根拠 に基づいている ([441])。 また、非対称暗号方式 (Asymmetric Cryptography) とも呼ばれる。
クレデンシャル (Credentials) 資格、信任状、信用証明書とも訳されている。 ユーザの ID の正当性を確認するもの。パスワード、X509 証明書または証明書連鎖、あるいはユーザを 確認するその他のあらゆるトークンが、資格となる場合があります。
権限委譲 (Delegation) あるメッセージに対する応答として、別のオブジェクトのメッセージを発行するオブジェクトの能力。委 譲は継承の代わりに使用できる。
証明書プロファイル (Certificate Profile) RFC2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile) により定義される。汎 用的な X.509 証明書に対して使用方法を限定することで、アプリケーションの実装を容易にする。
準拠テスト スイート (Conformance Test Suite) 標準に準拠しているかどうかを確認するためのテストパッケージ。
信頼ドメイン (Trusted Domain) Trusted domain – 信頼された (trusted) ドメインであり、このドメインのユーザは下の Trusting Domain に対するアクセス権を持つ。 Trusting domain – 他のドメインのユーザにアクセスを許可するドメイン。
セキュア API (Secure API) オープンなネットワークを介して, 企業間でセキュアな通信機能を提供するセキュリティの API。
セキュリティ API (Security API) 公開鍵の生成, 公開鍵証明書の発行機能、セキュリティ ライブラリを用いて暗号化・復号, 電子署名生成・ 検証等の機能を利用する際の, アプリケーションインタフェース。
セキュリティ パターン (Security Patterns) Open Group が現在進めている “Guide to Security Patterns (GSP)” というプロジェクトで議論されて いるテーマである。このプロジェクトの目的は、現場のデザイナや設計者が直面する情報セキュリティ設 計問題を解決し、安定したセキュリティ アーキテクチャを設計するためのチュートリアル形式のガイドを 提供することである。現在限定メンバーに対してパブリック レビューの段階であり、最終版がバージョン 1 として 2002 年 6 月に発行される予定である。現在進行中のプロジェクトであり、成果はまだ出ていない。
274 このプロジェクトに関しては、次の URL を参照： http://www.opengroup.org/security/gsp.htm
属性証明書 (Attribute Certificate) 属性証明機関 (AA) が発行。証明書に添付する主体者の属性を指定。 公開証明書をパスポートに例えると、属性署名書はパスポートに添付するビザにあたる。
蓄積交換方式 (Store and Forward) 各ノードで一度パケット全体を溜める、パケット転送方式。
デジタル証明書 (Digital Certificate) 日常使用している、運転免許証、クレジットカード、図書カード、保険証などの紙やプラスチックの ID ト ークンの電子的な等価物。
バイオメトリックス (Biometrics) 身体的あるいは行動上の特徴を元に人物を自動的に認識する方法。
バイオメトリック認証 (Biometric Authentication) 対象者の身体的特徴（指紋、網膜等）や身体的特徴（筆跡、音声等）などの対象者個人に固有の情報を予 め予測してシステムに登録しておき、取引の都度測定する本人の特徴・特性が登録データと合致するかど うかによって相手の真正性を確認する方法である。 また、バイオメトリックス認証、バイオメトリクス認証とも訳され、本論分ではバイオ認証という略語も 用いている。
275
付録 8. 参考資料
[1] INTAP (財団法人 情報処理相互運用技術協会) http://www.intap.or.jp/ [2] INTAP、『平成 8 年度セキュリティ技術調査報告書』、平成 9 年 3 月。 http://www.net.intap.or.jp/INTAP/information/report/h8-sec/index.html 備考) 2001 年まで上記 URL でファイルが入手できたが、2002 年より公開が中止されたため現在入手不可能。分書 中、「第 3 章 各種セキュリティ API」、「付録 2 第 2 回海外調査報告」に API 関連の記述がある。 [ 3 ] "The Microsoft Internet Security Framework: Technology for Secure Communication, Access Control, and Commerce", Microsoft Corporation, December 20, 1996. http://msdn.microsoft.com/library/en-us/dnsecure/html/msdn_misf.asp http://www.microsoft.com/windowsce/smartcard/resources/wp-ref.asp [ 4 ] "Microsoft Internet Commerce Strategy: A Foundation for Doing Business on the Internet", Microsoft Corporation, May 1997. http://msdn.microsoft.com/library/en-us/dnsite/html/msdn_commercestrat.asp [5] Jeff Ogden, "Microsoft Internet Security Framework (MISF)" http://www.eece.unm.edu/faculty/rjordan/595-025/jeff/MISF_presentation.html [6] RSA Security Inc. http://www.rsasecurity.com/ [7] News, "Microsoft, RSA Data Security and Security Dynamics Announce Broad Relationship to Deliver Information Security Solutions ", August 1996. http://www.rsa.com/news/pr/960821-2.html [8] Denise Ecklund (Intel), "CDSA Technology", July 1998. http://www.opengroup.org/security/meetings/jul98/intel_cdsa.pdf [9] John G. Spooner, "Intel getting inside open source", ZDNet News, April 10, 2000 http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2523586-1,00.html [10] 日刊アスキー Linux、「米 Intel、セキュリティソフトウェア『Common Data Security Architecture 3.0』をオープンソースに」、2000 年 4 月 12 日。 http://linux.ascii24.com/linux/news/today/2000/04/12/print/434752.html [11] 「セキュリティソフトをオープンソース化する Intel の狙い」、2000 年 4 月 10 日。 http://www.zdnet.co.jp/news/0004/11/intel1.html [12] Intel, CDSA site http://www.intel.com/ial/security/ [13] Aram Perez (Apple Computer Inc), "Apple's Security Architecture (ASA)", July 1998 Meeting Proceedings, July 21, 1998. http://www.opengroup.org/security/meetings/jul98/apple_cdsa.pdf [14] Compaq, True64 Unix site http://www.tru64unix.compaq.com/unix/security-internet.htm [15] Stephen Hillier (Entrust Technologies Limited), "CDSA and the Entrust PKI", July 1998 Meeting Proceedings, July 21, 1998. http://www.opengroup.org/security/meetings/jul98/entrust_cdsa.pdf [16] Sekar Chanersekaran (IBM), "IBM Keyworks", July 1998 Meeting Proceedings, July 21, 1998. http://www.opengroup.org/security/meetings/jul98/ibm_cdsa.pdf [17] "Intel's CDSA Gains Acceptance in Linux, Biometrics Spaces", September 25, 2000. http://www.securitywatch.com/newsforward/default.asp?AID=4011 [18] Sri Myneni (Motorola), "Motorola CipherNET Software Developers' Kit", July 1998 Meeting Proceedings, July 21, 1998. http://www.opengroup.org/security/meetings/jul98/motorola_cdsa.pdf [19] Intel Architecture Labs http://www.intel.com/ial/ [20] Oregon State University, Information Security Laboratory, http://security.ece.orst.edu/documents/intel/ 備考) http://security.ece.orst.edu/documents/README には、 “The material found in this directory is for distribution within the Lab only.” の但し書きがある。 [21] Richard Sargent, "CDSA Explained - An indispensable guide to Common Data Security Architecture", The Open Group, 1998.
276
[22] "CDSA-CSSM 2.0 and CDSA-CSSM 1.2 - Differences in Specifications", April 1998. http://www.opengroup.org/security/meetings/apr98/Diffs.pdf [23] Ruth Taylor (NSA), "A Comparison of CDSA to Cryptoki", October 18, 1999. http://csrc.nist.gov/nissc/1999/program/taylor/taylor.pdf [24] IAL, "Common Data Security Architecture", June 21, 2000. ftp://download.intel.com/ial/security/CDSA_overview.pdf [ 25 ] Lelia Barlow (Intel), "CDSA Now Includes Biometric Authentication, Authorization", Intel Developer UPDATE Magazine, September 2000. http://developer.intel.com/update/departments/initech/it09003.pdf [26] Eric Greenberg (Netscape Communications Corporation), George Cox (Intel Architecture Labs), "Intranet Security: Overview of Security-enabled Communications". http://developer.netscape.com/docs/presentations/archivedconf/fall96/trb_9.pdf [27] Common Data Security Architecture - Frequently Asked Questions http://developer.intel.com/ial/security/faq.htm [28] Terry A. Smith (Intel), "CDSA Adoption Gains Momentum (Common Data Security Architecture)", September 27, 2000. http://www.tesiconsortium.org/news/CDSApresISSE2000.pdf [29] "Integration CDSA into OpenSSL", November 20, 2000. ftp://download.intel.com/ial/security/CDSA_OpenSSL.pdf [30] David Bowler (Intel), "SSL and CDSA", June 22, 2000. ftp://download.intel.com/ial/security/CDSA_SSL.pdf [31] Bull, TrustWay site http://www.servers.bull.com/trustway/ [ 32 ] Open Group Technical Standard, "Common Security: CDSA and CSSM, Version 2 (with corrigenda)", May 2000. http://www.opengroup.org/publications/catalog/c914.htm 備考) PDF は http://www.opengroup.org/onlinepubs/009608599/toc.pdf [33] "Intel Security Program", July 1998. ftp://download.intel.com/ial/security/intelsp.pdf [34] Mona Vij (Intel), "Conformance Test Suite (CTS)", June 21, 2000. ftp://download.intel.com/ial/security/CTS.pdf [35] Ian Lloyd (The Open Group), "Testing and Certification", July 27, 2000. ftp://download.intel.com/ial/security/TOG_certification.pdf [36] SourceForge, CDSA Project http://sourceforge.net/projects/cdsa/ [37] Open Source, Apple CDSA site http://www.opensource.apple.com/projects/cdsa/index.html [38] John Wilson (Intel), "Proposals for Future CDSA Extensions - User Authentication Services", July 1998. http://www.opengroup.org/security/meetings/jul98/uas-tog.pdf [39] Charles Blauner, (J.P. Morgan&Co. Inc.), "Electronic Commerce - The Emerging Public Key Infrastructure; Standards and Trends - Architecture & APIs", 21st National Information Systems Security Conference http://csrc.nist.gov/pki/documents/cdsa.ppt [40] John Wilson (Intel), "Java for CDSA", April 1998 Meeting Proceedings, April 1998. http://www.opengroup.org/security/meetings/apr98/cdsa-java.pdf [41] TESI Subproject: interfacing JCA/JCE with CDSA http://tesijava.sourceforge.net/ [42] David Bowler, "Human Recognition Services (HRS)", Intel Corporation, June 21, 2000. http://www.intel.com/ial/security/documentation.htm ftp://download.intel.com/ial/security/CDSA_HRS.pdf [43] ジェミー・ジョウォルスキー、ポール・ペローネ著、『Java2 セキュリティ プログラミング - 基礎概 念から実装の詳細まで』、2001 年 4 月 25 日、(株)ピアソン・エデュケーション [44] Java Security サイト http://java.sun.com/security/ [45] "Secure Software Engineering, Mobile Code Security". http://www.cs.kuleuven.ac.be/~frank/OVS/MobileCodeSecurity.ppt [46] "J2SE Security: Present and Future" presentation from JavaOne 2000. http://servlet.java.sun.com/javaone/javaone2000/pdfs/TS-1175.pdf [47] Jay Wallace, "Java Security Architecture", October 17, 2001.
277
http://sern.ucalgary.ca/courses/SENG/513/F2001/slides/JavaSecurity.ppt [48] Scott Oaks, "Java Security (2nd Edition)", O'Reilly & Associates, Incorporated, May 2001. [49] Li Gong (Sun), "Java 2 Platform Security Architecture Version 1.0", October 2, 1998. http://java.sun.com/j2se/1.3/docs/guide/security/spec/security-spec.doc.html [50] The Java 2 Platform, Standard Edition, Version 1.3 http://java.sun.com/j2se/1.3/ [51] Java Platform Ports http://java.sun.com/cgi-bin/java-ports.cgi [52] Martin Rentz (GemsStone), "GemStone/J 4.0", GemStone Systems, June 28, 2000. http://www.jugs.org/jfs2000/folien/A3_Rentz_gemstone.pdf [53] "Frequently Asked Questions (FAQ) for the Java 2 Platform, Standard Edition" http://java.sun.com/j2se/faq.html [54] "Java 2 SDK, Standard Edition Documentation, Version 1.3.1" http://java.sun.com/j2se/1.3/docs.html [55] "J2SDK, v 1.3 Security Documentation" http://java.sun.com/j2se/1.3/docs/guide/security/index.html [56] Open Group Guide, "Architecture for Public-Key Infrastructure (APKI)", Document Number: G801, March 1999. http://www.opengroup.org/pubs/catalog/g801.htm [57] Open Group Guide, "Architecture for Public-Key Infrastructure (APKI) Draft 1", May 1997. http://www.opengroup.org/public/tech/security/pki/apki_1-0.pdf [58] Bob Blakley (IBM), "Architecture for Public-Key Infrastructure (APKI)", January 31, 1997 http://security.ece.orst.edu/documents/IBM/apkipres.pdf [59] Preliminary DCN/ICN August 1999 Technology Refreshment Assessment", August 1999. 備考) なお、この文書は http://www.dcnicn.com/ から削除されており、Google のキャッシュにより過去の情報を 検索した。 [60] Open-Source PKI (OSPKI) Book site http://ospkibook.sourceforge.net 備考) "OSPKI Book" project tries to collect the necessary information to create a document that describes Public-Key Infrastructures, current PKI standards, explains practical PKI functionality and gives an overview of available open-source PKI implementations. Its goal is to foster the creation of a high quality open-source PKI. [61] INTAP コンテンツ配信技術委員会、「Telematica Instituut レポート」 http://www.net.intap.or.jp/INTAP/cdn/cdn_2-8.pdf [62] Ian Foster and Carl Kesselman, "The Grid: Blueprint for a New Computing Infrastructure", Morgan Kaufmann Publishers, July 1998. http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-475-8 [63] "Ninf Security Architecture (Draft)" http://ninf.apgrid.org/~nakada/ninf/memo/authentication.html [64] "The Globus Toolkit: Basics" http://www.globus.org/training/toolkit-internals/02-Basics.pdf [65] Steven Tuecke (ANL), "Grid Security Infrastructure (GSI) Roadmap", October 17, 2000. http://www.gridforum.org/security/gf5_2000-10/presentations/gf5_GSI_Roadmap_Intro.pdf [66] The Globus Project, "Grid Architecture" http://www.globus.org/training/grid-architecture/GridArchitecture.pdf [67] Download the Globus Toolkit http://www.globus.org/toolkit/download/ [68] Charlie Catlett (Global Grid Forum), "Global Grid Forum, A Primer and Invitation to Participate", October 2001 http://www.gridforum.org/Presentations/GGF-History-Overview-Oct2001.pdf [69] The Globus Project, "Introduction to Grid Computing and the Globus Toolkit" http://www.globus.org/training/grids-and-globus-toolkit/IntroToGridsAndGlobusToolkit.pdf [70] "Grid Security Infrastructure" http://www.globus.org/training/toolkit-internals/04-Security.pdf [71] Welch, Tuecke, Engert, Meder, "GSS-API Extensions", September 2001. http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf [72] Michael Russell (University of Chicago), "Java Globus Development Plan", May 2001. http://www-unix.globus.org/cog/doc/devplan-latest.doc [73] The Globus Toolkit, Release 1.1.3 http://www.globus.org/toolkit/download/release-113.html
278
[74] Globus インストールマニュアル日本語版 http://www.jaist.ac.jp/~kohiga/globus/install.html [75] Globus, Related Work http://www.globus.org/about/related.html [76] Industry supports the Globus Toolkit http://www.globus.org/business/news/20011112a.html [77] the Globus Project http://www.globus.org/ [78] Globus Frequently Asked Questions http://www.globus.org/about/faq.html [79] core Globus Project Team http://www.globus.org/about/team.html [80] Globus, Collaborators http://www.globus.org/about/collaborators.html [81] Globus, Sponsors http://www.globus.org/about/sponsors.html [82] Grid Security Infrastructure (GSI) Grid Forum Security Area http://www.gridforum.org/security/gsi/index.html [83] Globus, Security APIs http://www.globus.org/developer/api-reference.html [84] Draft-ggf-gss-extensions-04.txt, Welch, Tuecke, Engert, Meder, "GSS-API Extensions", September 2001. http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf [85] GSI, a standalone version of the Globus Security Infrastructure ftp://ftp.globus.org/pub/gsi/gsi-latest.tar.gz [86] Grid Security Infrastructure (GSI) http://www.globus.org/security/ [87] Globus Toolkit Documentation http://www.globus.org/toolkit/documentation/ [88] "Globus 1.1 Overview" http://www.globus.org/v1.1/overview/v1.1_overview.pdf [89] "Introduction to Java GSSAPI: Concepts and features" http://service2.boulder.ibm.com/devtools/news0401/art25.htm [90] C441, X/Open Preliminary Specification, "Generic Security Service API (GSS-API) Base", X/Open Company Ltd., December 1995. [91] RFC1964, J. Linn, "The Kerberos Version 5 GSS-API Mechanism", June 1996. [92] RFC2025, C. Adams, "The Simple Public-Key GSS-API Mechanism", October 1996. [93] Simple Public Key GSS-API Mechanism (SPKM) http://www.systinet.com/products/gss/doc/spkm.html [94] RFC2743, J. Linn, "Generic Security Service Application Program Interface, Version 2, Update 1", January 2000. [ 95 ] Amgad Fayad, Don Faatz (MITRE), MITRE TECHNICAL REPORT, "Security Services Application Programming Interface (SS API) Developer's Guidance", March 2000. http://www.mitre.org/support/papers/tech_papers99_00/fayad_ss_api/fayad_ss_api.pdf [96] Carlisle M. Adams (Nortel), "Independent Data Unit Protection GSS API (IDUP) - 05.txt UPDATE -", June 24-28, 1996. http://www.ietf.org/proceedings/96jun/area.and.wg.reports/sec/cat-slides-96mar.ppt [97] PyGSS: Python bindings for the GSS-API http://sourceforge.net/projects/pygss [98] SECUDE - Security Development Environment for Open Systems http://www.darmstadt.gmd.de/secude/technical.htm [99] Entrust, GSS-API Toolkit for C https://www.entrust.com/developer/session/index.htm [100] RFC2203, M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol Specification", September 1997. [101] RFC1508, J. Linn, "Generic Security Service Application Program Interface", September 1994. [102] RFC1509, J. Wray, "Generic Security Service API: C-bindings", September 1993. [103] RFC2744, J. Wray, "Generic Security Service API Version 2: C-bindings", January 2000. [104] RFC2853, J. Kabat, "Generic Security Service API Version 2: Java Bindings", June 2000. [105] RFC2478, E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", December 1998.
279
[106] IETF http://www.ietf.org/ [107] RFC のダウンロードサイト http://rfc.kpnqwest.fi/ , http://globecom.net/ietf/ , http://www.alliedtelesyn.co.nz/resources/resources.html など [108] X/Open Guide, "Security Survival - Source Book from The Open Group", edited by Dean Adams, Jan. 1997. [109] The Open Group http://www.opengroup.org/ [ 110 ] Jalal Al-Muhtadi, M. Dennis Mickunas, Roy H. Campbell, "SGSS-API Documentation and Developers' Guide", Report No. UIUCDCS-R-99-2141, UILU-ENG-99-1760, August 1999. http://www.cs.uiuc.edu/Dienst/Repository/2.0/Body/ncstrl.uiuc_cs/UIUCDCS-R-99-2141/pdf [111] "SASL GSSAPI mechanisms", draft-ietf-cat-sasl-gssapi-05.txt [112] Java SASL API http://www.worldspot.com/jsr28/doc-publicreview/overview-summary.html [113] CryptoAPI (SDK Documentation) http://msdn.microsoft.com/library/en-us/security/portalapi_3351.asp [114] Microsoft Cryptographic Service Providers http://msdn.microsoft.com/library/en-us/security/cryptoref_4dmb.asp [ 115 ] Richard Bondi, "Cryptography for Visual Basic: A Programmer's Guide to the Microsoft CryptoAPI", Wiley, John & Sons, Incorporated, July 2000. [116] Cryptographic Service Providers (SDK Documentation) http://msdn.microsoft.com/library/en-us/security/portalcsp_0alh.asp [ 117 ] NSA Cross-Organization CAPI Team, "Security Service API: Cryptographic API Recommendation," First Editiotn, National Security Agency, June 12, 1995. http://www.omg.org/docs/1995/95-06-06.ps, ftp://ftp.omg.org/pub/docs/1995/95-06-06.ps [118] CRYPTOGRAPHY FOR VISUAL BASIC http://www.cryptovb.com/ 備考) 文献[115]に関する情報を提供するサイト。文献[115]によると、このサイトで WCCO 1.0 の最新版を公開してい く予定としているが、2001 年 11 月 8 日現在、コードおよびパッチは提供されていない。 [119] CryptoObject http://www.cryptoobject.com/ [120] AspEncrypt.com http://www.aspencrypt.com/ [121] CryptoAPI Tools (SDK Documentation) http://msdn.microsoft.com/library/en-us/security/portaltool_3u3p.asp [122] Intel Platform Security Division, "Accessing the Intel Random Number Generator through a CSP of Microsoft CryptoAPI", 1999. http://developer.intel.com/design/security/rng/rng-capi.htm [123] Compaq の製品パフレット、"TrustMaster CSP" http://nonstop.compaq.com/docs/IO/1470/ATT/atrisppd.pdf、 http://www.compaq.com/products/quickspecs/10502_div/10502_div.HTML、 http://www.aster.si/partnerji/compaq/atalla/trust.html また、日本語の資料が以下のページに掲載されている。 http://www.compaq.co.jp/products/himalaya/atalla/trust.html、 http://www.compaq.co.jp/press/press255.html [124] Aaron Margosis, Patrick Arnold, "Microsoft CryptoAPI Overview and an (fine) Example of CAPI Application Development", CSRC, Federal PKI Technical Working Group http://csrc.nist.gov/pki/twg/presentations/twg-99-51.pdf [125] nAble Strategic Alliance Partner: Microsoft http://www.ncipher.com/partners/profile_microsoft.html [126] David Cross (Microsoft Corporation) and William A. Franklin (nCipher, Inc), "Windows 2000 Server and PKI: Using the nCipher Hardware Security Module", Technical White Paper, April 7, 2001. [127] Microsoft's Support for Open Security Standards (Technical Articles) http://msdn.microsoft.com/library/en-us/dnsecure/html/msdn_openness.asp [128] Platform SDK Update Site http://www.microsoft.com/msdownload/platformsdk/setuplauncher.asp [129] Microsoft Platform SDK http://developerstore.com/devstore/product.asp?productID=7639&Store=TOOLBOX_INTL&DisplayCode
280
[130] MSDN Library http://msdn.microsoft.com/library/ 備考) Microsoft のサイトは今年頭に構成変更があり、過去に引用されているリンクでエラーになるケースが今年頭 に構成変更があり、過去に引用されているリンクでエラーになるケースが多々ある。 本資料で紹介している CryptoAPI、CAPICOM、CSPs のページは、2001 年 11 月現在、[113], [116], [128], [112929] など の URL で参照できる。 [131] Thi Chau Nguyen-Huu (Secured Communications Inc.), "The Real World implementation of CAPI". http://download.nai.com/products/media/pgp/ppt/sci-demo.ppt [132] Microsoft Corporation, "Microsoft CryptoAPI, Application Programmer’s Guide, Preliminary, Version 1", July 1996. http://security.ece.orst.edu/documents/microsoft/Crypto1_0.doc [133] Sunanda R. Menon (Intel), "CSSM Core Services", June 21, 2000. ftp://download.intel.com/ial/security/CSSM.pdf [134] Graham Bird (The Open Group), "CDSA Program Update - The Open Brand", April 1998 Meeting Proceedings, May 06, 1998. http://www.opengroup.org/security/meetings/apr98/CDSA-brand.pdf [135] RFC2479, C. Adams (Entrust Technologies), "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)", December 1998. http://www.ietf.org/rfc/rfc2479.txt [136] Ingris, Secuer Office Client http://www.integris.se/secureoffice/pdf/socW.pdf [137] Draft-ietf-cat-idup-gss-07.txt, C. Adams (Entrust Technologies), "GSS API Independent Data Unit Protection Generic Security Service", March 25, 1997 http://www.meehan.cs.wwu.edu/nw3courses/cs417f/common/gssapi/idup_gss.htm [138 ] Draft-ietf-cat-idup-cbind-03.txt, S. Klump (Entrust Technologies Ltd.), D. Thakkar (Entrust Technologies Ltd.), "Independent Data Unit Protection Generic Security Service Application Program Interface: C-bindings", May 1, 1997. [139] Amgad Fayad (MITRE), "DII COE Security Services Architecture Framework (SSAF)", January 27, 2000. http://www.mitre.org/support/papers/tech_papers99_00/dii_coe_presentation/、または、 http://www.mitre.org/support/papers/tech_papers99_00/dii_coe_presentation/ diicoe.ppt [140] MITRE, Security Services Application Programming Interface (SS API) Developer's Security Guidance http://www.mitre.org/support/papers/tech_papers99_00/fayad_ss_api/index.shtml [141] Bob Miller (SAIC), "DII COE 4.X Status", April 25, 2001. http://pmatccs.monmouth.army.mil/diicoe/briefs/25april2001/dii_coe_4x_status.ppt 備考) 現在、上記の資料は入手不可能で、Google のキャッシュでのみアクセス可能。 [142] DII COE, Configuration Management https://dod-ead.mont.disa.mil/cm/cm_page.html [143] DII COE FAQ http://diicoe.disa.mil/coe/faq/faq_page.html [144] "米国防情報システム局が、SGI IRIX 6.5.3 オペレーティング･システムを国防情報基盤共通操作環境 (DII COE)として準拠認証", 2000 年 8 月 7 日。 http://www.sgi.co.jp/newsroom/press_releases/2000/aug/compliance.html [ 145 ] NSA, "Convergence Strategy for DISA’ s DII COE Security Services APIs and NSA’ s Cryptographic APIs", March 4, 1999. http://www.disa.mil/coe/aog_twg/twg/sstwg/Convergence0304.ppt [146] "DII COE 4.X Security Service APIs & Netscape Security Services (NSS) Binding" http://www.disa.mil/coe/coeeng/SECURITY_PAGES/nss.ppt [147] Julie Mintz, "COE Production Engineering Status", September 7, 2001. http://www.disa.mil/coe/aog_twg/aog/sep01aog.ppt [148] COE Release Information http://www.disa.mil/coe/coeeng/RELEASE_PAGES/Rel_Info.htm [149] Quang Nguyen (DISA), "COE Security Update", September 7, 2001. http://www.disa.mil/coe/aog_twg/aog/08_AOG_Sept_01_security_update.ppt [150] MITRE http://www.mitre.org/ [151] DII, Common Operating Environment Home Page http://diicoe.disa.mil/coe/
281
[152] DISA (DEFENSE INFORMATION SYSTEMS AGENCY) http://diicoe.disa.mil/ [153] Java Cryptography Extension (JCE) http://java.sun.com/products/jce/ [154] Java Cryptography Extension (JCE) 1.2.1 http://java.sun.com/products/jce/index-121.html [155] Java Cryptography Extension 1.2 http://java.sun.com/products/jce/index-12.html [156] Java Cryptography Extension (JCE) for the Java 2 SDK, Standard Edition, v 1.4 http://java.sun.com/products/jce/index-14.html [157] Sharon Liu, Jan Luehe, "How We Made the Java(TM) Cryptography Extension Exportable", the RSA 2000 Conference slides http://java.sun.com/products/jce/jce-rsa2000-html-files/rsaSlides.ppt.htm [158] Java Cryptography Extension 1.2.1, API Specification & Reference http://java.sun.com/products/jce/doc/guide/API_users_guide.html [159] JCE 1.2.1 API Specification http://java.sun.com/products/jce/doc/apidoc/index.html [160] Java Cryptography Extension (JCE), Reference Guide, for the Java 2 SDK, Standard Edition, v 1.4 http://java.sun.com/j2se/1.4/docs/guide/security/jce/JCERefGuide.html [161] Cryptix Foundation, LTD http://www.cryptix.org/ [162] Cryptix JCE http://www.cryptix.org/products/jce/index.html [163] How to Implement a Provider for the Java Cryptography Extension 1.2.1 http://java.sun.com/products/jce/doc/guide/HowToImplAProvider.html [164] Java Cryptography Extension (JCE) 1.2.1, Cryptographic Service Providers and Clean Room Implementations http://java.sun.com/products/jce/jce121_providers.html [165] JCE 1.2, Cryptographic Service Providers and Clean Room Implementations http://java.sun.com/products/jce/jce12_providers.html [166] Cryptix Foundation Limited http://www.cryptix.org/ [167] Cryptix JCE http://www.cryptix.org/products/jce/index.html [168] Cryptix 3 http://www.cryptix.org/products/cryptix31/ [169] Java Cryptography Extension (JCE) 1.2.1 FAQ http://java.sun.com/products/jce/jce121_faq.html [170] JCE 1.2.1 software license http://java.sun.com/products/jce/jce121_license.txt [171] Download JCE 1.2.1 software, policy files, and documentation. http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=8&PartDetailId=JCE-1_2_1-G-F&TransactionId= Try [172] Download JCE 1.2 API Specification (HTML) http://javashoplm.sun.com/servlet/LoadManagerServlet/ECom/docs/Welcome.jsp?StoreId=8&PartId=JCE&Part DetailId=JCE-12-DOC-G-F&TransactionId=Try [173] Download JCE 1.2 Software http://javashop.sun.com/ECom/docs/Welcome.jsp?StoreId=8&PartDetailId=JCE-12-GEN-D-F&TransactionId=t ry [174] Download JCE Unlimited Strength Jurisdiction Policy Files http://java.sun.com/j2se/1.4/index.html#jcepolicyfiles [175] Java Secure Socket Extension (JSSE) http://java.sun.com/products/jsse/ [176] PersonalJava 3.1 http://java.sun.com/products/personaljava/ [177] Java Secure Socket Extension (JSSE) 1.0.2, FAQ http://java.sun.com/products/jsse/FAQ.html [178] Java Secure Socket Extension (JSSE) 1.0.2 http://java.sun.com/products/jsse/index-102.html
282
[179] Wayne Schroeder, “Informal description of our investigation of Java SSL packages”, August 31, 1999 http://www.sdsc.edu/~schroede/java_ssl_notes.html [180] Brad R. Wetmore (Sun Microsystems, Inc.), "Java Secure Socket Extension (JSSE) API", slides for JavaOne 2000, July 21, 2000. http://java.sun.com/products/jsse/JavaOne00_JSSE.pdf [181] JSSE 1.0.2 API Specification http://java.sun.com/products/jsse/doc/apidoc/index.html [182] Java Secure Socket Extension (JSSE) Reference Guide for the Java 2 SDK, Standard Edition, v 1.4 http://java.sun.com/j2se/1.4/docs/guide/security/jsse/JSSERefGuide.html [183] iPlanet http://docs.iplanet.com/ [184] Release Notes for iPlanet Application Server (iAS EPE) http://docs.iplanet.com/docs/manuals/iaspro/60/sp3/relnotes.html [185] iPlanet Release Notes for BuyerXpert 4.1 SP3 http://docs.iplanet.com/docs/manuals/buyer/41/sp3/bx41sp3RN.html [186] JSSE 1.0.2 software license http://java.sun.com/products/jsse/LICENSE.txt 「187」 Download JSSE 1.0.2 domestic (US/Canada) software and documentation http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=JSSE-1.0.2-GEN-D-JS&Transac tionId=Try [188] Download JSSE 1.0.2 global software and documentation http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=JSSE-1.0.2-GEN-GL-JS&Trans actionId=Try [189] Java 2 SDK, Standard Edition, v 1.4.0 Beta 3 (J2SE) http://java.sun.com/j2se/1.4/ [190] Java Secure Socket Extension (JSSE) for the Java 2 SDK, Standard Edition, v 1.4 http://java.sun.com/products/jsse/index-14.html [191] Java Secure Socket Extension (JSSE) 1.0.2 API User's Guide http://java.sun.com/products/jsse/doc/guide/API_users_guide.html [192] "Introduction to JAAS and Java GSS-API Tutorials" http://java.sun.com/j2se/1.4/docs/guide/security/jgss/tutorials/index.html [193] Java Security http://java.sun.com/j2se/1.4/docs/guide/security/index.html [194] Systinet (formerly Idoox) http://www.systinet.com/index.html [195] Systinet, WASP Server Advanced for Java http://www.systinet.com/products/wasp_advanced/index.html [196] Systinet, WASP GSS/SPKM Security Framework http://www.systinet.com/products/gss/index.html [197] Jan Alexander (Idoox), "Java GSS-API implementation Announcement", April 06, 2001 http://www.ittc.ukans.edu/~ansecure/public_html/0095.html [198] JGSS Package Distribution Page http://choices.cs.uiuc.edu/Security/JGSS/jgss.html [199] GSS-API/Kerberos v5 Authentication http://java.sun.com/products/jndi/tutorial/ldap/security/gssapi.html [200] "Use of Java GSS-API for Secure Message Exchanges Without JAAS Programming" http://java.sun.com/j2se/1.4/docs/guide/security/jgss/tutorials/BasicClientServer.html [201] "Use of JAAS Login Utility and Java GSS-API for Secure Message Exchanges" http://java.sun.com/j2se/1.4/docs/guide/security/jgss/tutorials/ClientServer.html [202] "More Things You Can Do With Java GSS-API and JAAS" http://java.sun.com/j2se/1.4/docs/guide/security/jgss/tutorials/MoreToDo.html [203] "When to use Java GSS-API vs. JSSE" http://java.sun.com/j2se/1.4/docs/guide/security/jgss/tutorials/JGSSvsJSSE.html [204] "Introduction to Java GSSAPI: Concepts and features" http://service2.boulder.ibm.com/devtools/news0401/art25.htm [205] IPA/ISEC http://www.ipa.go.jp/security/ [206] IPA/ISEC、電子政府情報セキュリティ基盤技術開発（平成 12 年度）
283
http://www.ipa.go.jp/security/products/fy12/egov.html [207] IPA/ISEC、 電子政府情報セキュリティ技術開発（平成 13 年度） http://www.ipa.go.jp/security/products/fy13/egov.html [208] 三菱電機(株)、(株)NTT データ、(株)日立製作所、日本電気(株)、「Crypto-API アーキテクチャ設計書」、 2001 年 2 月 28 日版。 [209] 大山永昭(東京工業大学)他、「Cypto-API の開発」、IPA/ISEC 平成 12 年度 電子政府情報セキュリテ ィ基盤技術開発事業、2001 年 6 月 12 日。 http://www.ipa.go.jp/security/kobo/12fy/report/H12-Mid-8-1.pdf [210] 三菱電機(株)、(株)NTT データ、(株)日立製作所、日本電気(株)、「Crypto-API セキュリティ機能要件 書」、2001 年 2 月 28 日版。 [211] 三菱電機(株)、(株)NTT データ、(株)日立製作所、日本電気(株)、「Crypto-API 機能設計書」、2001 年 2 月 28 日版。 [212] 三菱電機(株)、(株)NTT データ、(株)日立製作所、日本電気(株)、「Crypto-API 論理機能モデル書」、 2001 年 2 月 28 日版。 [213] OPSEC: Open Platform for Security http://www.checkpoint.com/opsec/index.html [214] OPSEC SDK http://www.checkpoint.com/opsec/sdkds.html [215] "Network Security for the Next Century", November 2000. http://www.checkpoint.com/press/2000/nwsecurity.pdf [216] Network Associates, Active Security http://www.nai.com/international/uk/asp_set/solutions/activesecurity/acts_intro.asp [217] Axent, Smart Security Architecture 備考) http://www.axent.com がアクセス不能により該当 URL 不明。 [218] IBM, Tivoli SecureWay FirstSecure 備考) http://www.tivoli.com/products/index/secureway_firstsecure/ によると、FirstSecure は 2001 年 7 月 31 日にマーケティングから撤退。 [219] "Check Point VPN-1/FireWall-1 OPSEC API Specification, Version 4.1.2", May 2000. OPSEC.pdf [220] Download the NG OPSEC SDK http://www.checkpoint.com/opsec/cp_products/opsec_sdk.html [221] "Check Point VPN-1/FireWall-1 Secure Authentication API Specification, Version 1.0", July 2000. SAA.pdf [222] "Check Point VPN-1/FireWall-1 CVP (Content Vectoring Protocol) API Specification, Version 4.1.2", May 2000. CVP.pdf [223] "Check Point VPN-1/FireWall-1 ELA (Event Logging API) Specification, Version 4.1.2", May 2000. ELA.pdf [224] "Check Point VPN-1/FireWall-1 LEA (Log Export API) Specification, Version 4.1.2", May 2000. LEA.pdf [225] "Check Point VPN-1/FireWall-1 OMI (Object Management Interface) API Specification, Version 4.1.2", May 2000. OMI.pdf [226] "Check Point VPN-1/FireWall-1 SAM (Suspicious Activities Monitoring) API Specification, Version 4.1.2", May 2000. SAM.pdf [227] "Check Point VPN-1/FireWall-1 UserAuthority API Specification, Version 4.1.2", May 2000. UACOPSEC.pdf [228] "Check Point VPN-1/FireWall-1 UFP (URL Filtering Protocol) API Specification, Version 4.1.2", May 2000. UFP.pdf [229] Join the OPSEC Alliance http://www.checkpoint.com/opsec/join.html [230] Download: Free Software http://www.opsec.com/opsecdownload.html [231] OPSEC Alliance http://www.checkpoint.com/opsec/info.htm [232] OPSEC Alliance Partner Listing http://www.checkpoint.com/opsec/allopsec.html [233] Introducing CAPICOM (Technical Articles)
284
http://msdn.microsoft.com/library/en-us/dnsecure/html/intcapicom.asp [234] Platform SDK: CAPICOM Reference http://msdn.microsoft.com/library/en-us/security/security/capicom_reference.asp [235] CAPICOM (SDK Documentation) http://msdn.microsoft.com/library/en-us/security/portalcom_357p.asp [236] CAPICOM (SDK Documentation) http://msdn.microsoft.com/library/en-us/security/security/capicom_start_page.asp [237] X/Open, Generic Cryptographic Services (GCS) http://www.xopen.org/public/tech/security/gcs/ [238] X/Open Preliminary Specification, "Generic Cryptography Service API (GCS-API) Base", X/Open Company Ltd., June 1996. [239] X/Open, Basic GCS http://www.xopen.org/public/tech/security/gcs/gcsbasic.htm [240] X/Open, Advanced GCS http://www.xopen.org/public/tech/security/gcs/gcs_adv.htm [241] Dennis Branstad and David Balenson (Trusted Information Systems, Inc.), "Summary of the Fourth International ICE/CAPI Workshop", December 3-4, 1996. http://www.pgp.com/research/nailabs/cryptographic/summary-fourth-ice.asp [ 242 ] "NATO C3 TECHNICAL ARCHITECTURE: A NEW "OPEN SYSTEMS" APPROACH FOR NATO", "2.8.3.3 Communication Security Services". http://194.7.79.15/Volume03/02-08-03-03.htm [243] Generic Cryptographic Service API (GCS-API) http://www.opengroup.org/publications/catalog/p442.htm [244] Comparison of The Open Group's GCS-API and Microsoft CryptoAPI Version 1.0 http://www.xopen.org/public/tech/security/gcs/ms_comp.htm [245] INTAP, OII サイト http://www.net.intap.or.jp/oiia/index.html [246] RSA Laboratories, PKCS #11 - Cryptographic Token Interface Standard http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/ [247] RSA Laboratories, Public-Key Cryptography Standards http://www.rsasecurity.com/rsalabs/pkcs/ [248] Ray Sidney (RSA Laboratories), "Cryptoki: The Cryptographic Token Interface Standard", 4th International ICE/CAPI Workshop, November 11, 1996. http://download.nai.com/products/media/pgp/ppt/sidney-cryptoki.ppt [249] "PKCS #11 V2.11 Final Draft: Crytographic Token Interface Standard", RSA Laboratories, June 2001. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v211/pkcs11v2-11.pdf [250] TC GPKCS11 http://www.trustcenter.de/products/pkcs11/en/en.htm [251] gpkcs11、最新版 0.7.2 ダウンロード用パッケージ (gpkcs11-0.7.2.tar.gz) http://prdownloads.sourceforge.net/gpkcs11/gpkcs11-0.7.2.tar.gz [252] PKCS#11 Implementations http://www.sec.nl/persons/janus/pkcs11/smartc.html [253] TC TrustCenter http://www.trustcenter.de 備考) TC TrustCenter AG is one of the leading provider for issuance and validation of digital certificates services. [254] News, "PKCS #11: New Member of Public Key Cryptography", January 12, 1994. http://www.rsasecurity.com/news/pr/940112-1.html [255] Mike Hamann (IBM Laboratory), "IBM GSCS Proposals for PKCS#11 Extensions", October 8, 1998. ftp://ftp.rsasecurity.com/pub/pkcs/98workshop/pkcs11proposals.doc [256] Chris J. Thorpe (Trusted Information Systems, Inc.), "Using Cryptoki with CryptoAPI for the ICE Project", Cryptoki Workshop, July 9, 1997. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/slides/thorpe.ppt [257] PKCS #11 FAQ http://developer.netscape.com/support/faqs/pkcs_11.html [258] Netscape DevEdge, Implementing PKCS #11 for the Netscape Security Library http://developer.netscape.com/docs/manuals/security/pkcs/index.htm [259] cryptlib
285
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ [260] IBM, PKCS11 API for Java http://www.alphaworks.ibm.com/tech/pkcs 備考) 2001 年には以下の URL で公開されていた。 http://www.alphaworks.ibm.com/formula/PKCS11APIforJava [261] Matthew Wood (Intel), "The CSSM PKCS #11 Adaptation Layer", RSA PKCS Workshop, October 8, 1998. ftp://ftp.rsasecurity.com/pub/pkcs/98workshop/pkcs11.ppt [262] Matthew Wood, "Use of PKCS #11 With the Common Data Security Architecture (CDSA)", July 1997. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/slides/wood.ppt [263] Java Cryptography Architecture API Specification & Reference, December 6, 1999. http://java.sun.com/j2se/1.3/docs/guide/security/CryptoSpec.html [264] Tutorial: Security Features Overview http://java.sun.com/docs/books/tutorial/security1.2/overview/index.html [265] Li Gong (SUN), "Java Security". http://sunsite.compapp.dcu.ie/IJUG/javaone/sessions/slides/TT03/TT03.pdf [266] How to Implement a Provider for the Java Cryptography Architecture http://java.sun.com/j2se/1.3/docs/guide/security/HowToImplAProvider.html [267] Java Cryptography Architecture API Specification & Reference, October 11, 2001. http://java.sun.com/j2se/1.4/docs/guide/security/CryptoSpec.html [268] Seraphim Research Group, "NodeOS Interface Specification (Addendum)", University of Illinois, May 22, 2000. http://choices.cs.uiuc.edu/Security/seraphim/May2000/NodeOS_API.pdf [269] "First Security Architecture Diagram", NAI LABS, July 2000. http://www.dsic-web.net:8501/pub/anets2000may/NAILabs.pdf [270] "GAA-API Reference Manual, version 0.3", June 27, 2001 http://www.isi.edu/gost/info/gaaapi/doc/refman.pdf [271] GAA-API, Software Distributions http://www.isi.edu/gost/info/gaaapi/distribution/gaa-announce.html [272] Keith R. Jackson, Mary Thompson (Lawrence Berkeley National Laboratory), "GAA Overview", March 26, 2000. http://www-unix.gridforum.org/mail_archive/security-wg/pdf00001.pdf [273] GAA-API, CHANGES history http://www.isi.edu/gost/info/gaaapi/distribution/changes.html [ 274 ] INTERNET-DRAFT, Tatyana Ryutov, Clifford Neuman, "Generic Authorization and Access control Application Program Interface: C-bindings", November 22, 2000. (Expires April 2001) draft-ietf-cat-gaa-cbind-05.txt http://community.roxen.com/developers/idocs/drafts/draft-ietf-cat-gaa-cbind-05.html [275] GAA-API, reference implementation http://www.isi.edu/gost/info/gaaapi/source/gaa-api-stand-alone.tar.gz [276] Code: gaa.tar http://www.isi.edu/~tryutov/code/gaa.tar [277] Code: gaa_java.tar http://www.isi.edu/~tryutov/code/gaa_java.tar [278] Tatyana Ryutov's GAA page http://www.isi.edu/~tryutov/gaa_api/gaa_api.html 279 Ho Chung's GAA page http://www.isi.edu/~hochung/research/gaa-api.html [280] Linux FreeS/WAN http://www.freeswan.org/ [281] Global Operating Systems Technology (GOST) Group http://www.isi.edu/gost/ [282] Generic Authorization and Access control API (GAA API) http://www.isi.edu/gost/info/gaaapi/gaa_api.html [283] O. Paridaens, "Report on 44th IETF Meeting", March 15th-19th, 1999. http://www.iihe.ac.be/internal-report/stc-99-04.html [ 284 ] Denis Pinkas (Bull S.A.), "Generic Authorization and Access control APIs (GAA-API) draft-ietf-cat-acc-cntrl-frmw-01.txt and Extended Generic Security Service APIs (XGSS-API) draft-ietf-cat-xgssapi-acc-cntrl-03.txt", January 8, 1999
286
http://www.ietf.org/proceedings/98dec/slides/cat-linn-98dec/ [ 285 ] T. Ryutov, C. Neuman, "Access Control Framework for Distributed Applications", draft-ietf-cat-acc-cntrl-frmw-05.txt, November 28, 2000. http://www.ietf.org/internet-drafts/draft-ietf-cat-acc-cntrl-frmw-05.txt [286] GAA-API, Document & Papers http://www.isi.edu/gost/info/gaaapi/doc/doc.html [287] GSI (Grid Security Infrastructure) http://www.globus.org/security/ [288] "Globus 1.1 Overview", July 30, 1999. http://www.globus.org/v1.1/overview/v1.1_overview.pdf [289] Draft-ietf-cat-xgssapi-acc-cntrl-03.txt, Tom Parker (ICL), Denis Pinkas (Bull), "Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions", November 09, 1998. http://www.globecom.net/ietf/draft/draft-ietf-cat-xgssapi-acc-cntrl-03.html [290] IETF の Internet Draft のアーカイブ http://www.watersprings.org/pub/id/index-wgc.html [ 291 ] S307, X/Open Snapshot, "Generic Security Service API (GSS-API), Security Attribute and Delegation Extensions", January 1994. [292] Draft-ggf-gss-extensions-04.txt, Welch, Tuecke, Engert, Meder, "GSS-API Extensions", September 2001. http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf [ 293 ] Draft-ietf-cat-sesamemech-02.txt, ERIC BAIZE (BULL), STEPHEN FARRELL (SSE), TOM PARKER (ICL), "The SESAME V5 GSS-API Mechanism", November 22, 1996. [294] “SESAME V4 GSS-API Application Developers' Guide” http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/gss_adg.txt [295] O. Paridaens, "Report on 43rd IETF Meeting", December 7th-11th, 1998, Orlando (US) http://www.iihe.ac.be/internal-report/stc-98-15.doc [296] Bruce Rich, Anthony Nadalin and Theodore Shrader, "All that JAAS: An overview of the Java authentication and authorization services", March 2000. http://www6.software.ibm.com/devtools/news0300/artpag28.htm [297] Java Authentication and Authorization Service (JAAS) サイト http://java.sun.com/products/jaas/ [298] Java Authentication and Authorization Service (JAAS) 1.0, Frequently Asked Questions http://java.sun.com/products/jaas/faq.html [299] Raghavan N. Srinivas, "Java Security Evolution and Concepts, Part 4: Optional Packages", Reprinted from JavaWorld, July 2001. http://developer.java.sun.com/developer/technicalArticles/Security/optionalpackages/index.html [300] "Java Authentication and Authorization Service (JAAS) Reference Guide for the Java 2 SDK, Standard Edition, v 1.4" http://java.sun.com/j2se/1.4/docs/guide/security/jaas/JAASRefGuide.html [301] Charlie Lai, "Java Authentication and Authorization Service (JAAS)", JavaOne 1999 http://java.sun.com/security/jaas/slides/javaone/index.html [302] Charlie Lai, Li Gong, Larry Koved, Anthony Nadalim, Roland Schemers, "Java Authentication and Authorization in Java Platform", ACSAC 1999 http://java.sun.com/security/jaas/slides/acsac/img0.htm [303] Java Authentication and Authorization Service (JAAS) 1.0, Developer's Guide http://java.sun.com/security/jaas/doc/api.html [304] JAAS Authentication Tutorial http://java.sun.com/j2se/1.4/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html [305] JAAS Authorization Tutorial http://java.sun.com/j2se/1.4/docs/guide/security/jaas/tutorials/index.html [306] Java Authentication and Authorization Service (JAAS) 1.0, LoginModule Developer's Guide http://java.sun.com/security/jaas/doc/module.html [307] IBM OS/2 Warp Developer Kit, Java(TM) 2 Technology Edition, Version 1.3 http://techsupport.services.ibm.com/asd-bin/doc/en_us/java13/f-feat.htm [308] Java Authentication and Authorization Service (JAAS) V1.0 for OS/390 Overview http://www-1.ibm.com/servers/eserver/zseries/software/java/jaas.html [309] Pramati Technologies http://www.pramati.com/ [310] Pramati Products http://www.pramati.com/products/index.htm
287
[311] Mayank Upadhyay, Ram Marti, "Single Sign-on Using Kerberos in Java" http://java.sun.com/j2se/1.4/docs/guide/security/jgss/single-signon.html [312] Tech Tips, July 27, 2001. http://developer.java.sun.com/developer/JDCTechTips/2001/tt0727.html [313] Open Group Publications, Authorization (AZN) API http://www.opengroup.org/publications/catalog/c908.htm [314] C908, Open Group Technical Standard, "Authorization (AZN) API", January 2000. http://www.opengroup.org/onlinepubs/009609199/toc.htm [315] Greg Clark (DASCOM, Inc.), "A Security Framework for the Enterprise". http://www.transarc.ibm.com/Decorum/DecArchive/99Presentations/day3/day3_e13.ppt [316] Tivoli Systems Inc. http://www.tivoli.com/ [317] Tivoli SecureWay Policy Director http://www.tivoli.com/products/index/secureway_policy_dir/ [318] "Tivoli SecureWay Policy Director, Technical Overview", October 22, 2001. http://www-5.ibm.com/de/software/university/presentations/mader-policy_director_overview.pdf [319] GCSS-AF home http://www.owego.com/gcss-af/ [320] Dan Smith, "GCSS-AF Security Overview", August 2000. http://web1.ssg.gunter.af.mil/gcss-af/IF/Library/GCSS-AF SecurityOverview AFTIC2000.ppt [ 321 ] "Establishing a Public Key Infrastructure", TechnologyAppraisals Security & Networking Seminars, November 2001. http://www.techapps.co.uk/pdfs/security/sns-pki4days.pdf [322] Linux-PAM サイト http://www.kernel.org/pub/linux/libs/pam/ [323] Charlie Lai (SunSoft), "Making Login Services, Independent of Authentication Technologies" http://www.sun.com/software/solaris/pam/pam_ste_talk.pdf [324] Open Software Foundation, "OSF Announces Integrated Login Solution, Security technology unites disparate authentication mechanisms into common infrastructure", December 11, 1995. http://www.sun.com/software/solaris/pam/osf-pr.html [325] Sun PAM, Service API man pages PDF 形式が http://www.sun.com/software/solaris/pam/man_pam_sm.pdf [326] Andrew G. Morgan, "The Linux-PAM Application Developers' Guide", DRAFT v0.75, March 18, 2001. http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl.html [ 327 ] Vipin Samar and Charlie Lai (SunSoft, Inc.), "Making Login Services Independent of Authentication Technologies", June 1998. PDF 形式が http://www.sun.com/software/solaris/pam/pam.external.pdf [328] SourceForge, PAM SMB サイト http://sourceforge.net/projects/pamsmb/ [329] Linux-PAM users http://www.kernel.org/pub/linux/libs/pam/whereislinuxpam.html [330] Sun Microsystems, PAM サイト http://www.sun.com/solaris/pam/ [331] D.H. Brown Associates, Inc. Report, "IBM Flexes UNIX - Muscle with AIX 5L", May 2001. http://www.tbc.co.uk/documents/analyst_reports/dh_brown_os_review.pdf [332] "Pluggable Authentication Modules information", Last update: January 28, 1998. http://www.dementia.org/~shadow/pam.html [333] Projects: Single Signon : Pluggable Authentication Modules for NT http://www.citi.umich.edu/projects/singlesignon/poster2.html [334] Linux-PAM, Modules/Applications available or in progress... http://www.kernel.org/pub/linux/libs/pam/modules.html [335] Solaris PAM http://www.sun.com/software/solaris/pam/ [336] "IBM Flexes UNIX, Muscle with AIX 5L", D.H. Brown Associates, May 2001. http://www.tbc.co.uk/documents/analyst_reports/dh_brown_os_review.pdf [337] CALDERA http://www.caldera.com/ [338] Theodore Ts'o, "Pluggable Authentication Modules (PAM)", January 9, 1996. http://www.usenix.org/publications/library/proceedings/ana97/IT/tso.ps
288
[ 339 ] V. Samar (SunSoft), R. Schemers (SunSoft), "UNIFIED LOGIN WITH PLUGGABLE AUTHENTICATION MODULES (PAM)", DCE/OSF-RFC86.0, October 1995. http://www.kernel.org/pub/linux/libs/pam/pre/doc/rfc86.0.txt.gz [ 340 ] A.G. Morgan (PAM working group), "Pluggable Authentication Modules", draft-morgan-pam-07.txt, October 6, 1999 http://www.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt [341] Open Group Preliminary Specification, "X/Open Single Sign-On Service (XSSO) - Pluggable Authentication", June 1997. http://www.opengroup.org/publications/catalog/p702.htm [342] Source code for PAM http://www.kernel.org/pub/linux/libs/pam/pre/ [343] Latest Linux-PAM tar ball http://www.kernel.org/pub/linux/libs/pam/pre/library/ [344] SourceForge PAM サイト http://sourceforge.net/projects/pam [345] SourceForge PAM, CVS http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pam/Linux-PAM/ [346] Rpmfind.Net http://rpmfind.net/ [347] Linux-PAM, Online documentation http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ [348] Linux-PAM, Offline documentation http://www.kernel.org/pub/linux/libs/pam/pre/doc/ [349] Sylvie Zapata-Brel (HP), "Introduction to the Personal Security Module (PSM), Integration of Smart Cards into the Pluggable Authentication Module (PAM)", Initial Draft Montserrat Mane (HP), March 1996. http://www.ri.silicomp.fr/os/psm/psm-wppr.htm [350] Java Authentication and Authorization Service (JAAS) 1.0 http://java.sun.com/products/jaas/index-10.html [351] Andrey V. Savochkin, Alexei V. Galatenko, Alexander A. Naumov, "Pluggable Non Interactive Authentication Modules", Oct 21, 1999. http://www.msu.ru/pniam/pniam.html [352] BUSINESS OBJECTIVES AND VALUES http://www.bioapi.com/BioAPI_objectives_files/biz.htm [353] 中山靖司、小松尚久、"バイオメトリックによる個人認証技術の現状と課題 - 金融サービスへの適用 と課題 -"、IMES Discussion Paper Series 99-J-43、1999 年 11 月。 http://www.imes.boj.or.jp/jdps99/99-J-43.pdf [354] John Wilson (Intel), "BioAPI Architecture", April 6, 2000. http://www.itl.nist.gov/div895/isis/bioapi/BioAPIpresentations/d_wilson.pdf [355] 中山 靖司、小松 尚久、「バイオメトリックスによる個人認証技術の現状と課題 ― 金融サービスへ の適用の可能性 ―」、金融研究第 19 巻別冊第 1 号、2000 年 4 月。 http://www.imes.boj.or.jp/japanese/kinyu/2000/yoyaku/kk19-b1-5.html http://www.imes.boj.or.jp/japanese/kinyu/2000/kk19-b1-5.pdf 備考) 本資料は文献[353]と内容はほぼ同じで、引用図や体裁を修正したものである。こちらの方が最新。 [356] "BioAPI Consortium Announces Release of Final Specification and Reference Implementation", March 20, 2001. http://www.bioapi.com/BioAPI_news_press_files/press_files/PR01-001.htm [357] The BioAPI Consortium, "BioAPI specification, Version 1.1", March 16, 2001. http://www.bioapi.com/BIOAPI1.1.pdf [358] Catherine J.Tilton (Saflink), "BioAPI- A Prescription for Biometric Interoperability in an Open System Environment", SECURE Magazine No.2, Spring 2001. http://www.silicon-trust.com/pdf/secure_2_pdf/opinion.pdf [ 359 ] Catherin Tilton (SAFLINK), "BioAPI, An Open Systems Interface Standard for Biometric Integration", July 11, 2001. http://www.ncits.org/minutes/0107ncits/it010719.pdf [ 360 ] Paul Griffin (Visionics Corporations), "Biometric Verification from a BSP Developer's Perspective", April 28, 2000. http://www.itl.nist.gov/div895/isis/bioapi/BioAPIpresentations/G_Griffin1.pdf [361] Steven Pomerantz (Kaiser Permanente), "BioAPI Application Development: Multiple Vendors and/or Multiple Biometrics", April 28, 2000.
289
http://www.itl.nist.gov/div895/isis/bioapi/BioAPIpresentations/M_Pomerantz v3.pdf [362] BioAPI Compliant Products http://www.bioapi.com/BioAPI_products/products.htm [363] CONSORTIUM MEMBERS http://www.bioapi.com/BioAPI_members_files/members.htm [364] BIOAPI FREQUENTLY ASKED QUESTIONS http://www.bioapi.com/BioAPI_faq_files/BioAPI_FAQ_rev4.htm [365] "BioAPI Consortium Announces Transition into ANSI Fast Track Standardization Process", September 20, 2001. http://www.bioapi.com/BioAPI_news_press_files/press_files/BioAPIPR01.htm [366] Version 1.1 BioAPI reference implementation http://www.bioapi.com/license.htm [367] Fernando L. Podio (NIST/ITL), "Motivation for a Biometric API, Purpose and Benefits", April 28, 2000. http://www.itl.nist.gov/div895/isis/bioapi/BioAPIpresentations/c_podio.pdf [368] "BioAPI Consortium Responds to Microsoft Biometric Announcement", May 8, 2000. http://www.bioapi.com/BioAPI_news_press_files/press_files/press050800.htm [369] Brigitte Wirts, Technofile4, "APIs and Interoperability" http://www.silicon-trust.com/background/mag_archive2.htm [370] Open Group Technical Standard, "CDSA/CSSM Authentication: Human Recognition Service (HRS) API V2", June 2001 http://www.opengroup.org/publications/catalog/c013.htm 備考)現在、上記ページの"FREE HTML"はリンクエラーでアクセス不能だが、下記 URL から本来メンバーのみが アクセス可能な PDF ファイルを入手することができる。 http://www.opengroup.org/onlinepubs/009698699/c013.pdf [371] IAL, Common Data Security Architecture, Specifications http://developer.intel.com/ial/security/specifications.htm [372] John H. Wilson (Intel), "BioAPI & CDSA / HRS Architecture", May 25, 2000. ftp://download.intel.com/ial/security/HRS_Architecture.pdf [373] Tom Spitzer, "Getting That Secure Feeling, Intel's Common Data Security Architecture and Microsoft's Crypto API", DBMS, June 1998. http://www.dbmsmag.com/9806d18.html [ 374 ] NSA Cross-Organization CAPI Team, "Security Service API: Cryptographic API Recommendation", First Editiotn, National Security Agency, June 12, 1995. http://www.omg.org/docs/1995/95-06-06.ps ftp://ftp.omg.org/pub/docs/1995/95-06-06.ps [ 375 ] NSA Cross-Organization CAPI Team, "Security Service API: Cryptographic API Recommendation", Second Editiotn, National Security Agency, July 1, 1996. http://fmg-www.cs.ucla.edu/classes/239_2.spring98/papers/capi19.html http://www.gitec.org/assets/pdfs/pdf96/capi.pdf [ 376 ] NSA Cross-Organization CAPI Team, "Security Service API: Cryptographic API Recommendation," Updated and Abridged Editiotn, National Security Agency, July 25, 1997. http://download.nai.com/products/media/pgp/pdf/nsacapi97.pdf [377] Cryptographic Technologies, International Cryptography Experiment (ICE) http://www.pgp.com/research/nailabs/cryptographic/international-cryptography.asp [378] Summary of the Second International Cryptography Experiment (ICE) Workshop http://www.nai.com/research/nailabs/cryptographic/crypto-summary.asp [379] "Summary of the Third International Cryptography Experiment (ICE) / Crypto API (CAPI) Workshop" http://www.pgp.com/research/nailabs/cryptographic/crypto-summary-third.asp [380] "Summary of the Fourth International ICE/CAPI Workshop" http://www.pgp.com/research/nailabs/cryptographic/summary-fourth-ice.asp [381] Chris J. Thorpe (Trusted Information Systems, Inc.), "Using Cryptoki with CryptoAPI for the ICE Project", Cryptoki Workshop, July 9, 1997. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/slides/thorpe.ppt [382] David M. Balenson (Trusted Information Systems, Inc.), "ICE Layered Security Architecture and Experimental Framework", Fourth International ICE/CAPI Workshop, December 3, 1996. http://download.nai.com/products/media/pgp/ppt/balenson-ice.ppt [383] Michael Elkins and Chris Thorpe (Trusted Information Systems), "ICE CAPI/CSP Development", Fourth International ICE/CAPI Workshop
290
http://download.nai.com/products/media/pgp/ppt/tis-demo.ppt [384] "International Cryptography Experiment (ICE) Status Report" http://www.pgp.com/research/nailabs/cryptographic/ice-status-report.asp [385] Peter Gutmann, "The Design of a Cryptographic Security Architecture", Proceedings of the 8th USENIX Security Symposium, August 23-26, 1999. http://www.usenix.org/publications/library/proceedings/sec99/full_papers/gutmann/gutmann.pdf [386] George L. Wooley､ "ISSO TRACK" http://csrc.nist.gov/nissc/1999/program/isso/sld060.htm [387] IATFF http://www.iatf.net/ [388] IATF Document 3.0 http://www.iatf.net/framework_docs/version-3_0/index.cfm 389 7.1 Security for System Applications http://www.iatf.net/framework_docs/version-3_0/pdffile.cfm?chapter=3ch07s1 [390] DII COE Security Services Architecture Framework (SSAF) http://www.mitre.org/support/papers/tech_papers99_00/dii_coe_presentation/index.htm [391] 2001 DII COE Technical Exchange, May 15 - 17 http://www.disa.mil/coe/dte/SegmentDeveloperTrack.htm [392] CNET News.com Staff, "HP has crypto export plan", November 18, 1996. http://news.cnet.com/news/0-1005-200-314497.html?tag=rltdnws [393] Posch R., "Security in the Global Information Infrastructure: Some newer Approaches to WWW security", Report IPTS, Sevilla, December 1996. http://dsa-isis.jrc.it/jrc-ecc/Crypto4WWW.pdf [394] UniNews online, "Government Cryptography Ruling Stirs Dissension - ICF is progress, but not enough, critics say", NniForum, December 13, 1996. http://www.uniforum.org/news/html/publications/uninews/961213/Inews1.html [395] Tivoli, Datasheets http://www.tivoli.com/products/documents/datasheets/ [396] Using Tivoli SecureWay to Manage e-business Security http://www.tivoli.com/products/documents/whitepapers/sway_ebus_security_wp.pdf [397] OSGi, Specification Overview http://www.osgi.org/resources/spec_overview.asp [398] Reprinted from ec/edi Insider, Volume 1, Issue 19, Washington Publishing Company, 1996. http://www.wpc-edi.com/Insider/Articles/V1/I-19r.html [399] RSA Security, News, "Apple, IBM, JavaSoft, Motorola, Netscape, Nortel, Novell, RSA, and Silicon Graphics Announce PICA Crypto-Alliance", Oct. 17, 1996. http://www.rsasecurity.com/news/pr/961017.html [400] Kelly Jackson Higgins, "The H-Report, News, trends and analysis", December 6, 1996. http://www.networkcomputing.com/720/720hr1.html [401] Kelly Jackson Higgins, "The Encryption Prescription", Dec. 9, 1996. http://www.internetweek.com/cwi/pages/120996/641close.htm [402] Dorothy E. Denning, "Dorothy E. Denning", May 17, 1997. http://www.cs.georgetown.edu/~denning/crypto/Trends.html [403] NIST, Development of a High-Level PKI Services API http://csrc.nist.gov/pki/pkiapi/welcome.htm [404] "High Level PKI Services API" http://csrc.nist.gov/pki/pkiapi/api0417.doc [405] Jalal Al-Muhtadi, M. Dennis Mickunas and Roy H. Campbell, “SGSS-API Documentation and Developers' Guide”, August 1999 http://ncstrl.cs.cornell.edu/Dienst/UI/1.0/Display/ncstrl.uiuc_cs/UIUCDCS-R-99-2141 http://www.cs.uiuc.edu/Dienst/Repository/2.0/Body/ncstrl.uiuc_cs/UIUCDCS-R-99-2141/pdf [ 406 ] Jalal Al-Muhtadi, "SGSS-API Documentation, SESAME GSS-API implementation in Java, Version 1.0a", http://choices.cs.uiuc.edu/Security/nephilim/Internal/sgssdoc/ [407] Jalal Al-Muhtadi, "SGSS-API Documentation and Developer's Guide" http://choices.cs.uiuc.edu/Security/nephilim/Internal/gss-api-report.pdf [408] The SESAME V5 GSS-API Mechanism http://choices.cs.uiuc.edu/Security/nephilim/draft-ietf-cat-sesamemech-02.txt [409] SESAME, A Secure European System for Applications in a Multi-vendor Environment http://www.esat.kuleuven.ac.be/cosic/sesame/
291
[410] SESAME documentation http://www.esat.kuleuven.ac.be/cosic/sesame/html/sesame_documents.html [411] SESAME V4 GSS-API Application Developers' Guide http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/gss_adg.txt http://www.esat.kuleuven.ac.be/cosic/sesame/doc-ps/gss_adg.ps [412] UIUC http://www.uiuc.edu/ [413] JSR 28, Rob Weltman, "Java SASL Specification", November 13, 2001. http://jcp.org/jsr/detail/28.prt [414] RFC2222, J. Myers (Netscape), "Simple Authentication and Security Layer (SASL)", October 1997. http://www.ietf.org/rfc/rfc2222.txt [415] RFC2444, C. Newman (Innosoft), "The One-Time-Password SASL Mechanism", October 1998. http://www.ietf.org/rfc/rfc2444.txt [416] Rohit Khare, "SNAPI vs CAPI", 27 Jan 1997. http://www.xent.com/FoRK-archive/winter96/0268.html [417] "Pluggable Non Interactive Authentication Modules" PNIAM http://www.msu.ru/pniam/pniam.html [418] PERMIS http://www.permis.org/ [419] What is PERMIS? http://www.permis.org/en/index.html [420] PERMIS, Privilege and Role Management Infrastructure Standards Validation http://sec.isi.salford.ac.uk/permis/ [421] David Chadwick, "PERMIS PMI", November 7, 2001. http://www.terena.nl/projects/pki/docs/pki-coord011126/PermisPMI.pdf [422] "Intel Protected Access Architecture - Application Interface Specification, Revision 1.0", March 2001. http://developer.intel.com/design/security/paa/IPAA-API-Rev1-01b.htm [423] RSA BSAFE page, "Product Standards Compatibility" http://www.rsasecurity.com/products/bsafe/standards.html [424] SECUDE - Security Development Environment for Open Systems http://www.darmstadt.gmd.de/secude/technical.htm [425] Welcome to the SECUDE-5.1 Hyper Link Documentation of the Application Interfaces! http://www.darmstadt.gmd.de/secude/Doc/htm/apiset.htm [426] SecuDE Homepage (DE) http://www.darmstadt.gmd.de/secude/ [427] Intel, With Intel Trusted Library, P2P Developers Can Live Happily Ever After http://cedar.intel.com/cgi-bin/ids.dll/content/content.jsp?cntKey=Generic+Editorial%3a%3aintel_p2p&cntType= IDS_EDITORIAL [428] Cryptographic Module Validation (CMV) Program http://csrc.nist.gov/cryptval/ [429] Peter Alterman, "The U.S. Federal PKI and the Federal Bridge Certification Authority" http://www.cio.gov/fbca/presentations/alterman-terena.ppt [430] Simple Public Key Infrastructure (spki) http://www.ietf.org/html.charters/spki-charter.html [431] SECOM、ネットワークセキュリティ読本、「6. 鍵管理、配布方式」 http://www.sisnet.or.jp/sis/dokuhon/p6.htm [432] Common Data Security Architecture, Specifications http://developer.intel.com/ial/security/specifications.htm [433] RFC2692, C. Ellison (Intel), "SPKI Requirements", September 1999. [434] RFC2693, C. Ellison (Intel), B. Frantz (Electric Communities), B. Lampson (Microsoft), R. Rivest (MIT Laboratory for Computer Science), B. Thomas (Southwestern Bell), T. Ylonen(SSH), "SPKI Certificate Theory", September 1999. [435] INTAP、『平成 9 年度セキュリティ技術調査報告書』、平成 10 年 3 月、「付録 海外調査報告」 http://www.net.intap.or.jp/INTAP/information/report/h9-sec/index.html [436] 「日経インターネットテクノロジ」、2000 年 10 月号。 [437] Cryptographic Libraries: A comparison http://www.homeport.org/~adam/crypto/table.html
292
備考) このページでは、”Comparison of various free (and free-world) crypto libraries”というタイトルで、暗号化 ライブラリのリストと比較を行っている。 2002/1/23 現在、上記 URL は参照不可となっており、Google のキャッシュでアクセスした。 [438] Encryption and Security-related Resources, “Crypto Software” http://www.cs.auckland.ac.nz/~pgut001/links/software.html [439] Encryption and Security-related Resources, “Security Standards, Laws, and Guidelines” http://www.cs.auckland.ac.nz/~pgut001/links/standards.html [440] Getronics Government Solutions, "S/MIME Freeware Library", August 27, 2001. http://www.ietf.org/proceedings/01aug/slides/smime-1/ [441] NetCocoon, 用語集 http://www.nais-netcocoon.com/jp/standard/netcocoon/word.html
293