This is a local copy of an original report by Andrew Colleran, Quercus Information Limited, Fax: +44 (0) 1865 436670, Tel: +44 (0) 1865 768902. Andrew.Colleran@quercus.co.uk http://web.ftech.net/~quercus/

Copies are available at: http://web.ftech.net/~quercus/ets/final1.zip and the European Commission site, http://www.cordis.lu/infosec/src/study4.htm

FINAL REPORT

Standardisation Issues for the European Trusted Services - ETS

by

Andrew Colleran

Quercus Information Ltd.

1.1 Purpose

1.2 Status

1.3 Priorities for action

2. SCOPE OF STUDY

3. REQUIREMENTS FOR STANDARDS

3.1 Who needs standards and why

3.2 Interoperability, portability and mobility

3.3 Types of standards required

3.4 Requirements on the process

3.5 Constraints on standards

4. THE STANDARDS PROCESSES

4.1 Formal standardisation

4.2 Industry groups and specifications

4.3 Internet standards

4.4 European standardisation

5. ROADMAP FOR THE FUTURE — THE WAY FORWARD FOR STANDARDS

5.1 Criteria for relevance of specifications and standards

5.2 Varieties of Trusted Services

5.3 Support services

5.4 Management standards

5.5 End services

5.6 Standards making issues

6. SPECIFICATIONS AND STANDARDS — CURRENT AND IN DEVELOPMENT

6.1 ISO/IEC JTC1/SC21 Open systems interconnection, data management and open distributed processing

6.2 ISO/IEC JTC1/SC27 IT Security techniques

6.3 ISO TC68 Banking, securities and other financial services

6.4 EDIFACT — Syntax Development Group of the United Nations Economic Commission for Europe (UN/ECE)

6.5 CEN

6.6 European Telecommunications Standards Institute — ETSI

6.7 Internet Engineering Task Force (IETF)

6.8 Object Management Group

6.9 Microsoft CryptoAPI

6.10 The Open Group

6.11 Public Key Cryptography Standards (PKCS)

6.12 Secure Electronic Transaction

7. PROJECTS AND STANDARDS

7.1 General Projects

7.2 Electronic Commerce

7.3 . The World Wide Web

7.4 Healthcare — TrustHealth

7.5 Telecommunications

7.6 Electronic mail

7.7 Electronic publishing, information broking, copyright management

7.8 Chip - Secure Electronic Transaction — C-SET

1. Summary of report
2. 1. Purpose
   2. There are two main purposes of this report: the first is to review the current standards and specifications which exist or are being developed, which are relevant for the establishment of Europe-wide trusted services; the second is to put forward a roadmap for future standards development work.
   3. Status

• • International Standards Organisation (ISO)
  • Internet Engineering Task Force (IETF)
  • European Telecommunications Standards Institute (ETSI)
  • European Committee for Standardisation (CEN).

1. 1. Priorities for action
   2. The main conclusions of the report and recommendations for action fall under two headings: content of standards and processes for their production. A more detailed roadmap is within the report. The underlying conclusion is that the technical standards, while not completely and formally ratified, are well advanced; what is required is a focus on implementation of applications using trusted services.
      1. Content of standards

• • Public key infrastructure to support digital signatures and other public key based operations such as non-repudiation:
  • • adopt X.509 v3, for certificate format
    • promote use of Lightweight Directory Access Protocol (LDAP) for access to directories
    • adopt the work of the IETF Public Key Infrastructure Group (PKIX), either as it is or as a source for other developments of trusted service infrastructures
    • certificates profiles — initiate action to minimise proliferation of certificate profiles and enable interoperability of certificates
  • Smart cards — in order to provide confidence in the use of services, develop standards that support smart cards, particularly for the Secure Electronic Transaction specification
  • Management standards (c.f. ISO 9000) — develop codes of practice and management guidelines to support mutual recognition of services by providers and to build confidence in services among users.

1. 1. 1. Standards making processes

• • The IETF, as a global forum for network standards development, should be the preferred place for the development of specifications and standards to support the growth of trusted service applications. The work being done on the Public Key Infrastructure is an example of such activity.
  • ISO work should focus on ratification of standards produced elsewhere, either in the IETF or in national bodies, if such ratification is needed by players in the market place.
  • Groups of market players should be established to increase involvement by users and operators in the development of guidelines for the operation of trusted services.
  • Standards work should be made more visible and efficient by the wider use of electronic media. This includes use of email discussion lists, document stores and directories of on-going work.

1.  
2. Scope of study

• • to review the standards and specifications which exist or are being developed which enable the establishment and operation of European Trusted Services
  • to identify what standards, specifications and other documents should be produced and
  • to propose how that work should be done.

• • identifies reasons for standards and specifications and their relevance to the establishment of European trusted services
  • considers the processes for producing standards and specifications
  • proposes a roadmap for future standards and specification related work
  • reviews current standards and specifications
  • examines the work of some projects relevant to standards and specifications for Trusted Services.

1.  
2. Requirements for standards
3. 1. Who needs standards and why
   2. 1. Users of the Information Infrastructure
      2. The Guidelines for Cryptography Policy recently published by the Organisation for Economic Co-operation and Development (OECD) emphasised the important impact on economic development and world trade of secure information and communications infrastructures. Trusted services are a major part of that infrastructure. There is thus a specific economic stimulus to the establishment of trusted services. The OECD Guidelines also highlight the need for international trade over open networks, with global interoperability, portability and mobility. For a user, interoperability means being able to work with a number of trusted services, without the need for special procedures such as data format conversion; portability means being able to move application solutions from one software and hardware environment to another and so the ability to combine an application with a choice of trusted services; mobility means being able to access the same trusted services, with the same functionality, when away from the usual place of work, particularly when in other countries.

         Users will also need to have confidence in the solutions and services they use. This confidence may be based on already existing bases, such as the market presence of a service provider or vendor; it may be based on the trust already placed in an organisation for other reasons, for example, the trust relationship between a bank and its customers; it may be based on a market accepted evaluation or licensing scheme for services. Management standards such as ISO 9000, which express at any particular time the current "standard practice" or "best current practice" in an area, have a role among users in developing and establishing confidence in trusted services which comply with them.

      3. Providers of Trusted Services

• • They wish to provide services to as wide a market as possible; interoperability with their potential clients is required; their clients will not all have the same application, software and hardware systems.
  • Service providers will need to establish relationships with other service providers, both in their own country and globally in order to support global transactions and the mobility of their customers, when away from their usual place of business; therefore technical interoperability among service providers is required.
  • For service providers, portability of solutions means the ability to move their application systems from one software and hardware environment to another, and the ability to combine an application with a choice of trusted services, thus protecting their investment in that application.

1. 1. 1. Solution vendors

1. 1. Interoperability, portability and mobility
   2. Interoperability, portability and mobility are required in solutions and services; they are very largely achieved by agreed standards covering protocols, data formats and program interfaces. By using agreed protocols and data formats, applications and systems can interoperate without the need to develop gateway services and conversion programs changing one format to another.

      Portability of solutions means they can be moved from one system environment to another and can be combined with a choice of trusted services; for users and service providers this means a protection of their investment in the deployment of the solution; for vendors it means a larger market for their solutions.

      Mobility means that users can move from place to place, country to country with no loss of service provided by their trusted service. For service providers, mobility means being able to provide what the user needs wherever he is.

   3. Types of standards required
   4. In order to meet the market requirements, technical standards are required to support interoperability, portability and mobility. Management standards, (cf. ISO 9000) may be needed to assist service providers to establish global relationships and for users to have confidence in their service providers. Standards for evaluation of systems and services may also be required, in order to build confidence in the services provided.
   5. Requirements on the process

• • openness — that is, the methods by which a standard is produced should be open to participation by all those concerned by the resulting standard; the phases of standard production should also be visible, preferably with versions of standards being published electronically.
  • market driven — the standard should correspond to the developments of the market and its evolution, as reflected by the introduction of new products and services. This is especially relevant to the area of trusted services, which is a market still in an immature and introductory phase. Promotion of particular solutions, whether on a technical or regulatory basis, which do not correspond to the market trends, is likely to lead to an ineffective standard.
  • consensus — standards, by definition, represent an agreement; the strongest and most effective standards are those with the widest agreement, developed by consensus of the parties concerned by their production.

1. 1. Constraints on standards

1.  
2. The Standards processes
3. 1. Formal standardisation

• • JTC1/SC21 Open systems interconnection, data management and open distributed processing
  • JTC1/SC27 IT Security techniques
  • TC 68 Banking, securities and other financial services.

• • slowness of the process; a major factor is the extensive review process by national standards bodies.
  • conflict of interests; academics and researchers want ideal and perfect solutions, vendors and users want solutions which work now.
  • the process is a voluntary activity; those who represent the Information Technology market and can develop and review standards are not available when the pace of development speeds up.

1. 1. Industry groups and specifications

• • the Open Group, formerly X/Open
  • Object Management Group
  • World Wide Web Consortium (W3C)
  • European Computer Manufacturers Association (ECMA)

1. 1. Internet standards

• • technical excellence;
  • prior implementation and testing;
  • clear, concise, and easily understood documentation;
  • openness and fairness; and
  • timeliness.

• • standards track
  • non-standards track.

• • Experimental
  • Informational
  • Historic.

1. 1. European standardisation

• • the High Level Strategy Group
  • the Information and Communications Technology Standards Board (ICT SB).

1. 1. 1. High Level Strategy Group

• • electronic commerce in support of SMEs
  • broadband networks
  • home information services.

• • the ICT SB should be actively involved in the definition of SET 2 (smartcard version of SET, including the standards for terminal equipment) (recommendation 1)
  • a co-ordination process should be set up with SEMPER (ACTS project) which focuses on experimentation and trials (recommendation 2)
  • roles and activity domains of security trusted third parties in the field of electronic commerce to be rapidly clarified (recommendation 7)
  • business directories for electronic commerce to be developed (recommendation 8)
  • pan-European legal and regulatory environment for electronic commerce to be agreed (recommendation 9)
  • industry to develop conformity assessment procedures applied to electronic commerce security models and their corresponding implementations (recommendation 10).

1. 1. 1. Information and Communications Technology Standards Board (ICT SB)

• • to analyse and co-ordinate requirements for standards and specifications, based on real market needs
  • to translate requirements into plans for the creation of standards and specifications
  • to allocate standards and specification development to the most appropriate body.

1. 1. 1. CEN
      2. The European Committee for Standardisation (CEN) comprises the national standards bodies of Europe. CEN has a number of Technical Committees relevant to European Trusted Services. They are:

         the European Board for EDI Standardisation (EBES)

         Medical Informatics (TC 251)

         Smart cards (TC 224).

         Standards developed by CEN committees are approved as European Standards by the national standards bodies who comprise CEN’s membership.

      3. ETSI

1.  
2. Roadmap for the future — The way forward for standards
3. 1. Criteria for relevance of specifications and standards
   2. A number of criteria have been used to select which specifications and standards are particularly relevant to the establishment of trusted services in Europe; individual standards may qualify under more than one heading. This report does not cover standards or specifications of particular cryptographic algorithms.
      1. Widely adopted for current services
      2. Industry, by its widespread adoption of a particular standard, is a strong indicator of the importance of a formal standard or a specification, which has the status of a de facto standard. Examples of such standards in the area of trusted third parties are the X.509 standard, the PKCS series (e.g. for key management, digital signatures, and certificate management), and the Microsoft Cryptography API.
      3. Developed by an open, industry wide body
      4. Development and promulgation of a standard, based on implementation experience, in an open manner, in a standards body which is open in its membership, is an important factor towards the general acceptance of its work. The PKI specifications being developed by the Internet Engineering Task Force (IETF) are examples of standards relevant under this heading. Work done in ISO/IEC JTC1 also qualifies under this heading.
      5. Developed by an industry wide consortium
      6. A number of industry consortia have been established with the objective of developing and publishing specifications. Because of their position in the market, the work of these consortia is significant. Among the specifications under this heading is the CORBA Security Specification, developed by the Object Management Group.
      7. Supporting open public network services
      8. Specifications and standards are only considered if they support or enable the provision of secure services over open public networks.
      9. Of general applicability
      10. Specifications and standards whose applicability is limited to one particular area of administration or commerce are not considered.
      11. International or European

      Standards and specifications are only considered if they are international or European.

   3. Varieties of Trusted Services
   4. The term "Trusted Service" describes a wide variety of services which provide different types of service to different users, whether they are application programs or human beings. One useful distinction is that between support services and end services. The classification is not rigid: some end services may be also regarded as support services. Making the distinction however is useful because of the greater urgency which is associated with standards for support services.

      An example of an end service might be a confidential notarised messaging service. This end service is visible to the user and may be a basis for payment. In order to support this service, other services are required, such as key certification services, confidentiality services, and time-stamping services.

   5. Support services

• • Authentication: an authentication service verifies the identity of a user or service. It is used to provide the access rights associated with the user or service and to enable accountability in the use of the system, for example, through audit trails.
  • Authenticity and integrity of electronic documents and data: services which declare where documents come from and who is responsible for them.
  • Accountability: services which apply to user to user transactions and relationships, such as non-repudiation services.
  • Confidentiality: services which may include symmetric key management services (key generation and distribution) and key escrow/recovery.
  • Directories: services to provide information about users and services.
  • Timestamping: services to provide a time when events happen.

1. 1. 1. Public key technology

• • registration and certificate issuing services, which establish a relationship between a person or legal entity and a public key and produce a certificate recording that relationship and possibly more information about the person or entity, such as their professional or academic qualifications, their national identity number, their residence and so forth.
  • key generation, that is the generation of a public/private key pair, which may include the storing and distribution of key material using a smart card
  • certification revocation, in response to a users’ request when the key is no longer valid or has been compromised
  • certificate repositories, this includes filing of certificates, so making them available to users wishing to check the validity of certificates, and revocation of certificates
  • key archive services, that is the storage of a public key no longer in use with a timestamped record of when it was in use so that old electronic documents can be verified even after the time the associated public key was valid
  • time-stamping authorities, which provide a reliable time with a signature recording when a message digest is submitted to them.

• • public key delivery and verification interface
  • Certification Authority agent
  • local registration authority
  • publication of certificates and CRLs.

1. 1. 1. Non-repudiation
      2. STATUS

         The Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) specification which is being produced by the Common Authentication Technology (CAT) working group of the IETF specifies a non-repudiation service. CORBA Security Services also specify a non-repudiation service.

         These services include both evidence generation and evidence verification.

      3. Symmetric key management services
      4. These services may generate the secret keys used by parties to communicate with confidentiality or may facilitate the transfer of secret keys between parties wishing to communicate with confidentiality.

         STATUS AND RECOMMENDATION

         The ETSI work on developing a TTP standard including key management, key escrow/recovery may be expected to provide solutions in this area. The standard being produced should be widely reviewed, under the aegis of the ICT Standards Board.

      5. Key escrow and recovery services.

• • if the user has lost the key
  • if the user is no longer able to provide the key, because of illness, absence etc. and the owner needs access to the information
  • when an employee, as a user, has left a company and there is a need by the data owner, the employer, to access files he has encrypted.

1. 1. 1. Directory Related Services
      2. Directory access

         The specifications being developed by the IETF Public Key Infrastructure (PKIX) group identify the Lightweight Directory Access Protocol (LDAP) as an important access method for retrieving information such as certificates. LDAP, developed by the IETF working group for Access, Searching and Indexing of Directories (ASID) has a wide applicability in networked applications and its use should be promoted. It is particularly suited to accessing X.500 directories but can also be used for access to directories implemented using other database technologies.

         STATUS AND RECOMMENDATION

         LDAP should be identified as a preferred access method for directories, in the open network environment, for use by SMEs and private citizens. Within corporate and closed environments other access methods, such as full X.500 directory access protocol, may be most appropriate.

      3. Time-stamping

1. 1. Management standards
   2. 1. Mutual recognition, accreditation of services and liability
      2. In order to support a network of Trusted Services, individual services will have to make mutual recognition agreements with each other about, for example, cross certification of each other’s certificates and mutual liability with respect both to the services offered and the holding of or access to related keys. These mutual agreements will be much easier and more effective if there are generally agreed codes of practice and management guidelines for the operation of trusted services.

         Accreditation of trusted services, which will promote development and acceptance of the services, also depends on the existence of these management standards.

         Agreements will have to be made between service providers and users about their mutual responsibilities and liabilities concerning the services offered and the cryptographic keys associated with them.

         STATUS AND RECOMMENDATIONS

         SC27 is working on the development of guidelines for the use and management of Trusted Third Parties.

         It is proposed that, since such standards are best produced by the operators of the trusted services themselves, a Europe-wide group be established to progress this subject.

      3. Evaluation

      A further element in developing accredited and assured services is the development of evaluation criteria.

      STATUS AND RECOMMENDATIONS

      The CCIB is undertaking work in this area with SC27 (ISO/IEC 15408 Evaluation criteria for IT Security); this work is not near completion. If a group is established to progress work on mutual recognition and accreditation, it is proposed that it review the CCIB and SC27 work and decide what shorter term steps are appropriate in this area. The work being done by TC36 of ECMA should also be reviewed. This work is currently represented by the draft standard of March 1997 entitled "Security Functionalities of the E-COFC (Extended Commercially Oriented Functionality Class for Security Evaluation )".

   3. End services

• • notary, that is attestation that something has been done
  • audit, that is recording of some action
  • archive, that is deposit of information, possibly in conjunction with notarisation
  • information broking, that is, being an intermediary in the relationship between the user of information and the provider
  • payment and billing, taking payment from users of information and other electronically distributed goods on behalf of providers, for example a copyright use and billing service
  • electronic messaging
  • registration services, holding information about the attributes of a person or legal entity; this service can also be seen as a support service to a service such as access control.
  • directory services, providing information about persons or legal entities so that they can be contacted; this service can also be seen as a support service.

1. 1. 1. Ad hoc groups

• • notarisation of contracts
  • transaction audit
  • document archiving
  • negotiable document trading
  • information broking
  • payment and billing
  • copyright use and billing service
  • electronic messaging
  • registration services
  • directory services.

1. 1. 1. Project exploitation

1. 1. Standards making issues

• • life cycle processes for technical and management standards — requirements to production
  • the role of European standardisation activities in relation to global activities
  • which bodies should make standards
  • the representation of public interest
  • the role of SMEs in standards making
  • incorporation of patented material in standards
  • the results of research and development projects.

1. 1. 1. Improving the processes

• • properly address the market requirements
  • include all the relevant parties and
  • are sufficiently open.

1. 1. 1. The role of European standardisation activities in relation to global activities

• • for a standard in a shorter time than can be achieved at the global level
  • for the incorporation of particular European views, possibly related to European level structures
  • to strengthen a European view for presentation to the rest of the world.

1. 1. 1. Standards making bodies.

• • International Standards organisation (ISO)
  • International Electrotechnical Commission (IEC), which is a member with ISO of the Joint Technical Committee 1 (JTC1)
  • International Telecommunications Union (ITU).

• • the formal bodies adopt a theoretical, top down approach to the development of standards, which is rigorous and bureaucratic
  • the IETF adopts a bottom up approach, which is driven by the need to implement solutions and is based on actual implementations; the process is closer to the needs of the market.

1. 1. 1. The representation of public interest

• • private citizens
  • consumer groups
  • SMEs
  • large corporations
  • special interest groups
  • public administrations
  • governments.

1. 1. 1. The role of SMEs in standards making

• • standards bodies should use the Internet, in particular electronic mail and web sites for document distribution
  • SMEs should be encouraged and assisted to use the Internet
  • organisations such as Chambers of Commerce should be used as a channel to promote greater awareness of the standards processes.

1. 1. 1. Incorporation of patented material in standards

• • the RSA algorithm, which is patented in the US; this is referenced in an informative annex to ISO 9796 (Digital signature scheme giving message recovery), and is not part of the formal standard.
  • the Diffie-Hellman algorithm, whose patent number 4200770 expired 29 April 1997, can now be freely used.
  • the Digital Signature Algorithm, published by NIST, is claimed to infringe other patents which have been granted internationally.

• • The patent holder waives his rights; hence, the specification is freely accessible to everybody, subject to no particular conditions, no royalties are due, etc.
  • The patent holder is not prepared to waive his rights but would be willing to negotiate licenses with other parties on a non-discriminatory basis on reasonable terms and conditions. Such negotiations are left to the parties concerned and are performed outside the ITU.

1. 1. 1. Research and development projects and standards

1.  
2. SPECIFICATIONS and standards — Current and in development
3. This section considers existing standards and specifications which are relevant to the setting up and operation of Trusted Services. The standards are considered according to the committee or group which has produced them.
   1. ISO/IEC JTC1/SC21 Open systems interconnection, data management and open distributed processing

• • it defines a framework for the provision of authentication services;
  • it defines a certificate format for public keys.

1. 1. 1. Framework for Authentication Services
      2. In defining a framework, the standard recommends the use of strong authentication, involving credentials formed using cryptographic techniques, as the basis for providing secure services.

         The strong authentication method described in the X.509 framework is based on public key cryptosystems. The standard notes a major advantage of such systems that user certificates may be held within the Directory as attributes, and may be freely communicated within the Directory System and obtained by users of the Directory in the same manner as other Directory information. The standard assumes that user certificates are formed by "off-line" means, and placed in the Directory by their creator. The generation of user certificates is performed by some off-line Certification Authority which is completely separate from the Directory System Agents (DSAs) in the Directory.

         The standard describes the process whereby one user is authenticated to another using a certificate which contains a public key and is signed by a Certification Authority which the user trusts. This process is based on a certification path which logically forms an unbroken chain of trusted points in the Directory Information Tree between two users wishing to achieve authentication.

         How keys and certificates should be managed forms a part of the standard. The responsibilities of a Certification Authority and a procedure for the revocation of certificates are described. Revocation of certificates is covered extensively in an amendment to the standard.

         The authentication framework described in X.509 does not depend on the use of a particular cryptographic algorithm, but RSA is described in an Informative Annex.

         Other Annexes which are not part of the recommendations are useful in describing security requirements and terms, and public key cryptography.

         In order to use systems following the standard, each user must possess a unique distinguished name. Two users wishing to achieve authentication must use the same public key cryptographic algorithm and hash function.

      3. The X.509 Certificate and Certificate Revocation Lists (CRL)

1. 1. additional information about the keys involved, including key identifiers for subject and issuer keys, indicators of intended or restricted key usage, and indicators of certificate policy;
   1. alternative names, of various name forms, for a certificate subject, a certificate issuer, or a CRL issuer, and additional attribute information about a certificate subject;
   1. allowing constraint specifications to be included in Certification Authority (CA)-certificates (certificates for CAs issued by other CAs), to facilitate the automated processing of certification paths when multiple certificate policies are involved, e.g. when policies vary for different applications in an environment or when interoperation with external environments occurs;

1. 1. ISO/IEC JTC1/SC27 IT Security techniques

• • mechanisms and techniques
  • management support documents and security guidelines.

1. 1. 1. Mechanisms and techniques
      2. In the first category are the following standards:

         ISO/IEC 9796:1991 Digital signature scheme giving message recovery

         ISO/IEC 9798 Entity authentication

         ISO/IEC 11770 Key management

         ISO/IEC 13888 Non-repudiation

         ISO/IEC 14888 Digital signatures with appendix

         SC27 does not currently standardise algorithms, although this may change soon if recommendations to work on algorithms are agreed. The standards therefore have a certain abstraction.

         1. ISO/IEC 9796:1991 Digital signature scheme giving message recovery
         2. ISO 9796 defines a scheme for verifying the originator and integrity of a block of data. The standard specifies a digital signature scheme giving message recovery for messages of limited length using a public key system (PKS). When the verification process reveals the message, the scheme is named a "signature scheme giving message recovery".

            It is primarily designed for the protection of small quantities of data such as cryptographic keys and the results of hashing longer messages.

            The standard does not mandate the use of a particular PKS or the size of the keys to be used. It is therefore necessary for users to agree algorithms and key sizes.

            Part 1 of the standard (on mechanisms using redundancy) is an International Standard. Part 2: (Mechanisms using a hash-function) is a draft International Standard (DIS) Part 3: (Mechanisms using a check function) and Part 4 (Discrete logarithm based mechanisms) are in working drafts (WD).

         3. ISO/IEC 9798 Entity authentication

• •  
  • identity based, where a trusted accreditation authority provides secret accreditation information which is a function of the claimant’s identity
  •  
  • certificate based, where a claimant has a public, private key pair and the verifier a trusted copy of the claimant’s public key (how this is achieved is beyond the scope of the standard, but it may be by using a certificate signed by a Trusted Third Party).

1. 1. 1. 1. ISO/IEC 11770 Key management

• • Point to Point, when two entities already share a secret key that can be used to establish further keys;
  • Key Distribution Centre (KDC) when the two entities do not share a secret key and the KDC generates and distributes the key and
  • Key Translation Centre (KTC) which converts and distributes keys for entities who do not already share a secret key

• • establish a shared secret key between two entities A and B by key agreement — the secret key is the result of a data exchange between the two entities A and B. Neither of them can predetermine the value of the shared key.
  • establish a shared secret key between two entities A and B by key transport — the secret key is chosen by one entity A and is transferred to another entity B, suitably protected by asymmetric techniques.
  • make an entity's public key available to other entities by key transport in an authenticated way (confidentiality is not required).

1. 1. 1. 1. ISO/IEC 13888 Non-repudiation

• • non-repudiation of origin
  • non-repudiation of delivery
  • non-repudiation of submission
  • non-repudiation of transport.

1. 1. 1. 1. ISO/IEC 14888 Digital signatures with appendix

1. 1. 1. Management support documents and security guidelines
      2. SC27 is responsible for the following management support documents and security guidelines:

         ISO/IEC 13335 Guidelines for the management of IT Security

         ISO/IEC 14516 Guidelines for the use and management of Trusted Third Parties

         ISO/IEC 15408 Evaluation criteria for IT Security.

         1. ISO/IEC 13335 Guidelines for the management of IT Security

• • determining IT Security objectives, strategies and policies
  • identifying and analysing security threats to IT assets
  • determining organisational IT Security requirements
  • managing IT Security risks
  • planning the implementation of adequate IT Security safeguards
  • developing a security awareness programme
  • planning follow-up programmes for monitoring, reviewing, and maintenance of security services
  • developing plans for incident handling.

1. 1. 1. 1. ISO/IEC 14516 Guidelines for the use and management of Trusted Third Parties

• • the roles, positions and relationships of Trusted Third Parties and other related entities (e.g. network service providers, end users, etc.)
  • the generic security requirements of Trusted Third Parties
  • the establishment of a security policy
  • the provision of security solutions and mechanisms
  • the operational use and management of TTP service security
  • the responsibilities of TTPs
  • the services which TTPs can provide
  • interworking of TTPs.

• • technique independent supplementary services, such as directory or public notary services
  • symmetric supplementary services, such as non-repudiation, key distribution or key translation
  • asymmetric supplementary services, examples are certified key assignment with or without key generation, and non-repudiation using asymmetric techniques.

1. 1. 1. 1. ISO/IEC 15408 Evaluation criteria for IT Security

• • the protection profile (PP) which allows creation of generalised reusable sets of security requirements.
  • the security target (ST) which expresses the security requirements and specifies the security functions for a particular product or system to be evaluated, called the target of evaluation (TOE).

1. 1. ISO TC68 Banking, securities and other financial services
   2. This committee has begun work on the subject of Trusted Third Parties and has looked at the work being done in JTC1 SC27 and ETSI Security TC. Although specific to the finance and banking sector, this work is of importance to the development of generic standards for trusted services, largely because of the experience and trusted status of the sector.
      1. Guidelines for Trusted Third Party services

• • assurance
  • services of a TTP
  • network of TTPs
  • legal issues.

1. 1. 1. 1. Assurance

• • Trust. Is the TTP organised, controlled and regulated in such a way that its operation can be relied upon, checked and verified?
  • Accreditation. Is the TTP accredited by recognised national, regional, or international groups?
  • Compliance. Is the TTP operating in compliance with accepted industry standards and all relevant regulation?
  • Contract. Is there a legally binding contract in place covering the provision of service and addressing all the relevant issues? Are there contracts with co-operating TTPs which also address these concerns?
  • Liability. Is there a clear understanding as to issues of liability? Under what circumstances is the TTP liable for damages? Does the TTP have sufficient resources or insurance to meet its potential liabilities?
  • Policy Statement. Does the TTP have a security policy covering technical, administrative, and organisational requirements?

1. 1. 1. 1. Services of a TTP

• • Key Management for symmetric cryptosystems
  • Key Management for asymmetric cryptosystems
  • Key Recovery
  • Authentication and Identification
  • Access Control
  • Non-repudiation

1. 1. 1. 1. Network of TTPs
         2. The guidelines, in recognising that the TTP concept is relatively new and a network of co-operating TTPs must be developed before the full potential of TTPs will be realised, warn financial institutions that they must be particularly vigilant in insisting that their TTP function maintain its assurances. Competition between suppliers may reduce costs at the risk of offering reduced levels of service or assurance. It is of paramount importance to preserve confidence in the institution and the financial service sector.
         3. Legal Issues

• • Archival and retrieval

• • Liability

• • Privacy

1. 1. 1. Certificate profile

1. 1. EDIFACT — Syntax Development Group of the United Nations Economic Commission for Europe (UN/ECE)

• • Independent time-stamping
  • Attribute certificates
  • Notary functions
  • Document repository
  • Non-repudiation of submission/delivery
  • Translation/validation of certificates.

1. 1. CEN
   2. 1. TC224 — Machine readable cards, related device interfaces and operations

• • recognition and authentication of all parties (e.g. customer, vendor, etc.);
  • ordering (including but not limited to order form, placement of order by the customer and acceptance of the order by the vendor);
  • agreement on the means of payment and related authorisation to pay by the customer;
  • payment authorisation (requested by the vendor to the financial institution);
  • payment request and impact on settlement.

1. 1. 1. TC251 — Medical Informatics

1. 1. European Telecommunications Standards Institute — ETSI
   2. The Security Technical Committee of ETSI is preparing a standard for Trusted Third Parties (TTP). The work is being done in a number of phases, starting with the production of a requirements report. The second phase is the production of the first standard. Current plans are to produce a standard for TTP services covering key management and key escrow/recovery.
      1. Requirements

• • general requirements, including the services to be provided
  • security requirements to be met by a TTP scheme
  • functional and interface requirements to be standardised.

1. 1. 1. Proposed first standard

1. 1. Internet Engineering Task Force (IETF)

• • Internet Public Key Infrastructure
  • Generic Security Services API
  • Lightweight Directory Access Protocol
  • S/MIME (Secure/Multipurpose Internet Mail Extensions)
  • PGP/MIME (MIME Security with Pretty Good Privacy)
  • Secure Sockets Layer
  • Simple Public Key Infrastructure
  • Domain Name System Security Extensions
  • Security Architecture for the Internet Protocol

1. 1. 1. Internet Public Key Infrastructure

• • Part I: X.509 Certificate and Certificate Revocation List Profile
  • Part 2: Operational Protocols
  • Part 3: Certificate Management Protocols
  • Part 4: Certificate Policy and Certification Practices Framework

1. 1. 1. 1. Part 1: X.509 Certificate and Certificate Revocation List Profile
         2. This specification profiles the format and semantics of certificates and certificate revocation lists for the Internet PKI. Procedures are described for processing of certification paths in the Internet environment. The specification presents profiles of the X.509 version 3 certificate and version 2 certificate revocation lists, work on which has been completed by ISO. This specification also includes path validation procedures.

            Finally, the specification describes procedures for identification and encoding of public key materials and digital signatures. Implementations are not required to use any particular cryptographic algorithms. However, conforming implementations which use the identified algorithms are required to identify and encode the public key materials and digital signatures as described.

            The goal of the specification is to develop a profile and associated management structure to facilitate the adoption and use of X.509 certificates within Internet applications for those communities wishing to make use of X.509 technology. Such applications may include WWW, electronic mail, user authentication, and IPSEC, as well as others. In order to relieve some of the obstacles to using X.509 certificates, this document defines a profile to promote the development of certificate management systems; development of application tools; and interoperability determined by policy, as opposed to syntax.

            Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialised application domains or environments with additional authorisation, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL).

            1. Architectural model of the Internet PKI

Figure 1 Internet PKI Model

The above figure shows the Internet PKI model. The components in this model are:

• • end entity: user of PKI certificates and/or end user system that the PKI certifies;
  • certification authority;
  • registration authority, i.e., an optional system to which a certification authority delegates certain management functions;
  • repository: a system or collection of distributed systems that store certificates and CRLs and serve as a means of distributing these certificates and CRLs to end entities.

1. 1. 1. 1. 1. The development of the Internet PKI
            2. The Internet Privacy Enhanced Mail (PEM) proposals, published in 1993, include specifications for a public key infrastructure based on X.509 v1 certificates (RFC 1422). The experience gained in attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats were deficient in several respects. Most importantly, more fields were needed to carry information which PEM design and implementation experience had shown were necessary. In response to these new requirements, ISO/IEC JTC/1 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organisation or community.

               ISO/IEC JTC/1 has also developed a set of standard extensions for use in the v3 extensions field. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints.

               Because the extensions are very broad in their applicability, in order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. it is the goal of this specification (Part 1) to define a profile for Internet WWW, electronic mail, and IPSEC applications. Other environments with additional requirements may build on this profile or replace it.

            3. Trust model

• • Internet Policy Registration Authority (IPRA) at the top of the hierarchy
  • Policy Certification Authorities (PCAs): distinct PCAs aim to satisfy different user needs and follow different policies.
  • Certification Authorities (CAs): which certify user entities

1. 1. 1. 1. Part 2 Operational protocols

• • the Lightweight Directory Access Protocol (LDAP) and
  • the File Transfer Protocol (FTP).

1. 1. 1. 1. Part 3: Certificate Management Protocols

• • between the end entity and the certification authority
  • • initial registration and certification
    • key pair recovery
    • key pair update
    • certificate update
    • revocation request.
  • between two certification authorities:
  • • cross-certification
    • cross-certificate update.
  • between the end user and the repository
  • • certificate publication
  • between the certification authority and the repository
  • • publication of certificates and certificate revocation lists

• • PKI management must conform to ISO 9594-8 and the associated draft amendment (DAM) (X.509 v3)
  • the use of confidentiality in PKI management protocols must be kept to a minimum in order to ease regulatory problems
  • PKI management protocols must allow the use of different industry-standard cryptographic algorithms, (specifically including, RSA, DSA, MD5, SHA-1) - this means that any given CA, RA, or end entity may, in principle, use whichever algorithms suit it for its own key pair(s)
  • PKI management protocols must not preclude the generation of key pairs by the end entity concerned, an RA or a CA
  • PKI management protocols must support the publication of certificates by the end entity concerned, an RA or a CA
  • PKI management protocols must support the production of CRLs by allowing certified end entities to make requests for the revocation of certificates
  • PKI management protocols must be usable over a variety of "transport" mechanisms, specifically including, mail, HTTP, TCP/IP and ftp.

1. 1. 1. 1. Part 4 Certificate Policy and Certification Practices Framework

• • community definition and applicability
  • identification and authentication policy for subjects, Registration Authorities and Certification Authorities
  • key management policy
  • non-technical security policy
  • technical security policy
  • operational requirements
  • legal & business provisions
  • certificate and CRL profiles and
  • policy administration.

1. 1. 1. 1. Architecture

• • System Security Enabling Services provide the functionality which allows a user's or other principal's identity to be established and associated with his actions in the system.
  • Cryptographic Primitives and Services provide the cryptographic functions on which public-key security is based (including secret-key primitives such as DES).
  • Long-term Key Services permit users and other principals to manage their own long-term keys and certificates and to retrieve and check the validity of other principals' certificates
  • Protocol Security Services provide security functionality (data origin authentication, data integrity protection, data privacy protection, non-repudiation) suitable for use by implementors of security-aware applications such as secure protocols.
  • Secure Protocols provide secure inter-application communications for security-unaware and "mildly" security-aware applications.
  • Security Policy Services provide the policy-related information which must be carried in secure protocols to enable access control, and provide access-control checking facilities to security-aware applications which must enforce policy.
  • Supporting Services provide functionality which is required for secure operation, but is not directly involved in security policy enforcement.

• • Cryptographic Service Interfaces
  • Long-term Key Services - protocols for
  • user workstation or smartcard to certificate management component
  • local registration authority to CA agent
  • public key delivery and verification

• • Long-term Key Services - interfaces for
  • virtual smartcard service
  • communication with hardware security tokens
  • public key delivery and verification interface
  • CA agent
  • local registration authority
  • publication authority (of certificates and CRLs)
  • Protocol Security Services - interfaces
  • session oriented services, GSS-API is preferred
  • store and forward services, IDUP-GSS-API is preferred
  • non-repudiation services, IDUP-GSS-API is preferred.

1. 1. 1. Generic Security Services API

• • documents defining specific parameter bindings for particular language environments
  • documents defining token formats, protocols, and procedures to be implemented in order to realise GSS-API services above particular security mechanisms.

• • data origin authentication with data integrity
  • data confidentiality with data integrity
  • non-repudiation services.

1. 1. 1. Lightweight Directory Access Protocol (LDAP)
      2. LDAP, a simplification of the X.500 directory access protocol (DAP), defines a reasonably simple mechanism for clients to query and manage a hierarchically structured database of attribute/value pairs over the Internet. The LDAP directory service model is derived from the X.500 model; use of LDAP does not require the existence of an X.500 directory. LDAP is a protocol for use between parties executing transactions on any hierarchical, attribute-based directory. The latest version of LDAP (version 3), which is currently a draft (draft-ietf-asid-ldapv3-protocol-03.txt), includes use of authentication mechanisms: password protection using a hash function, and certificate-based digitally signed token. Version 3 of LDAP can be carried over the Secure Socket Layer (SSL) protocol.
      3. S/MIME (Secure/Multipurpose Internet Mail Extensions)

• • authentication, message integrity and non-repudiation of origin (using digital signatures) and
  • privacy and data security (using encryption).

• • whether or not the PKCS-nn documents will be IETF RFCs or simply be referenced as external documents.
  • references to the encryption and hash algorithms.
  • use of the S/MIME trademark.

1. 1. 1. PGP/MIME (MIME Security with Pretty Good Privacy)

• • application/pgp-encrypted,
  • application/pgp-signature and
  • application/pgp-keys.

1. 1. 1. Secure Sockets Layer

• • the connection is private. Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption (e.g., DES), RC4)
  • the peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA, DSS)
  • the connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations.

1. 1. 1. Simple Public Key Infrastructure (SPKI)
      2. Two developments which have been progressing separately are now merging. They are proposals for a Simple Distributed Security Infrastructure and a Simple Public Key Certificate. A proposal for a Simple Public Key Infrastructure is now being developed.

         A Simple Distributed Security Infrastructure -- SDSI

         This is a proposal for a new distributed security infrastructure. SDSI principals are public digital signature verification keys with individuals controlling the associated private keys. No global hierarchy is necessary, but there is support for common roots such as DNS, Verisign and others. Each principal is a "certification authority" and manages a local name space with which he can refer to other principals.

         There are three types of certificate: identity certificate, name/value certificate, and membership certificate. Identity certificates have human-readable content and the process for creating them is manual.

         A key can delegate the authority to sign certificates on behalf of the key. The delegation can be limited to certificates that match a template. Certificates can time out, and they can be reconfirmed by an on-line agent acting for the issuer. SDSI is optimised for an on-line Internet environment in which clients can interact with servers to learn what credentials are needed to satisfy a request, and can retrieve the needed credentials from other severs.

         Simple Public Key Certificate

         An SPKI certificate has been defined as an authorisation certificate. It grants a specific authority to a public key rather than binding an "identity" (such as a person's name) to that key. For example, one SPKI certificate might grant permission for a given public key to authenticate logins over TELNET as user CME on host CYBERCASH.COM for some period of time.

         Requirements for a SPKI

         A defining characteristic of an SPKI certificate is that it is a text based structure which does not use ASN.1 to define its data structures. The main purpose of an SPKI certificate is to authorise some action, give permission, grant a capability, etc. The first requirement for an SPKI certificate is then to bind a meaningful or useful attribute to a public key (and therefore to the keyholder of the corresponding private key). In many cases, the attribute would not involve any recognisable name.

         The definition of attributes or authorisations in a certificate is up to the author of the application code which uses the certificate. The creation of new authorisations should not require interaction with any other person or organisation but rather be under the total control of the author of the code using the certificate.

         The main driving forces behind the proposal are the desire to keep down overheads arising from use of an ASN.1 based certificate and an infrastructure supporting a global directory, the search for an efficient implementation, and freedom and flexibility to develop structures for a growing number of applications.

      3. Domain Name System Security Extensions
      4. The Domain Name System (DNS) is a critical operational part of the Internet infrastructure but it has no strong security mechanisms to assure data integrity or authentication. This document describes extensions to the DNS which provide these services to security aware resolvers or applications through the use of cryptographic digital signatures, which are included in DNS files. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware name resolvers to learn the authenticating key of name zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. The document provides for a variety of key types and algorithms.
      5. Security Architecture for the Internet Protocol

• • authentication algorithm and algorithm mode being used with the IP Authentication Header
  • key(s) used with the authentication algorithm in use with the Authentication Header
  • encryption algorithm, algorithm mode, and transform being used with the IP Encapsulating Security Payload
  • key(s) used with the encryption algorithm in use with the Encapsulating Security Payload
  • lifetime of the key or time when key change should occur
  • lifetime of this Security Association
  • sensitivity level (for example, Secret or Unclassified) of the protected data.

1. 1. Object Management Group

• • authentication
  • audit of security relevant events
  • access control
  • message protection, such as integrity and confidentiality
  • non-repudiation, that is generation and verification of evidence of actions.

1. 1. Microsoft CryptoAPI

• • Key exchange algorithm
  • Digital signature algorithm
  • Key blob format
  • Digital signature format
  • Session key derivation scheme
  • Key length

• • key generation
  • storing and exchanging keys
  • encrypting and decrypting data
  • producing a message digest of data or a session key
  • signing a message digest
  • verifying a digital signature of a message digest.

1. 1. The Open Group

• • data encipherment and decipherment
  • integrity checkvalue generation and verification
  • production of irreversible hash of data
  • generation of random numbers.

• • generation, derivation and deletion of keys
  • export and import of keys.

• • application independence
  • independence of cryptographic algorithm and subsystem: that is, appropriate to both hardware and software implementations, and implementable on top of any cryptographic technology or cryptomodule
  • no constraints on future extensibility.

• • inquiry of available keys and key related data.

• • generation, derivation and deletion of keys, including public parameters
  • storage and retrieval of keys and associated information
  • archive and retrieval of keys and key related data.

1. 1. Public Key Cryptography Standards (PKCS)

• • PKCS #1: RSA Encryption Standard
  • PKCS #3: Diffie-Hellman Key Agreement Standard
  • PKCS #6: Extended-Certificate Syntax Standard
  • PKCS #7: Cryptographic Message Syntax Standard
  • PKCS #9: Selected Attribute Types
  • PKCS #10: Certification Request Syntax Standard

1. 1. 1. PKCS #1: RSA Encryption Standard
      2. PKCS #1 describes how data is encrypted using the RSA public-key cryptosystem. Its intended use is in the construction of digital signatures and digital envelopes, as described in PKCS #7. For digital signatures, before signing the content is first reduced to a message digest with a message-digest algorithm (such as MD5); signing is done by encrypting with the signer’s RSA private key the message digest. For digital envelopes, the content to be enveloped is first encrypted under a content-encryption key with a content-encryption algorithm (such as DES), and then the content-encryption key is encrypted with the RSA public key(s) of the recipient(s) of the content. PKCS #1 also describes a syntax for RSA public keys, which is identical to that in both X.509 and PEM, and for RSA private keys. The public-key syntax would be used in certificates.
      3. PKCS #3: Diffie-Hellman Key Agreement Standard
      4. PKCS #3 describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can establish a secret key which can then be used, for example, to encrypt further communications between the parties.
      5. PKCS #6: Extended-Certificate Syntax Standard
      6. PKCS #6 describes a syntax for extended certificates, consisting of an X.509 public-key certificate and a set of attributes, collectively signed by the issuer of the X.509 public-key certificate. Following the recent amendments to X.509, it has been suggested that there is no longer a need for this standard.
      7. PKCS #7: Cryptographic Message Syntax Standard
      8. PKCS #7 describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. The syntax supports recursion, so that, for example, one envelope can be nested inside another, or one party can sign some previously enveloped digital data Other attributes, such as signing time, can be authenticated along with the content of a message, and countersignatures can be associated with a signature.

         PKCS #7 does not cover issues such as the public key infrastructure, what entities certificate issuers are authorised to certify, what distinguished names are considered acceptable, and the policies certificate issuers must follow (such as signing with secure hardware, or requiring entities to present specific forms of identification). Dissemination of certificate-revocation lists is not covered.

      9. PKCS #9: Selected Attribute Types

• • for use in extended certificates
  • electronic-mail address
  • unstructured name
  • unstructured address
  • for use in digitally signed messages
  • content type
  • message digest
  • signing time
  • countersignature
  • for use in certification requests
  • challenge password
  • extendedcertificate attributes.

1. 1. 1. PKCS #10: Certification Request Syntax Standard

• • the postal address to which the signed certificate should be returned if electronic mail is not available
  • a "challenge password" by which the entity may later request certificate revocation;

1. 1. Secure Electronic Transaction

• • confidentiality of card account number
  • integrity of payment data
  • authentication:
  • • buyer knows seller is a secure merchant
    • seller knows buyer has a valid card account
  • interoperability between different brands of card

1. 1. 1. The participants
      2. Cardholder

         The holder of a card issued by an Issuer.

         Issuer

         The financial institution which establishes an account for the Cardholder and issues the card. The Issuer guarantees payment for authorised transactions made using the card in accordance with the regulations of the card association and local legislation.

         Merchant

         The merchant sells in exchange for payment. A merchant who wishes to enable his customers to pay electronically and securely must first have a relationship with an Acquirer.

         Acquirer

         An Acquirer is the financial institution that establishes an account with a merchant and processes card authorisations and payments.

         Payment gateway

         A payment gateway is a device operated by an Acquirer or a designated third party which processes merchant payment messages (including cardholders’ payment instructions).

         Association

         A grouping of financial institutions which promotes and protects the card brand, sets and enforces rules for the use and acceptance of the cards and provides networks connecting the financial institutions.

         Third parties

         Issuers and Acquirers sometimes assign the processing of card transactions to third parties. SET does not distinguish between the financial institution and the party processing the card transactions on its behalf.

      3. The processes
      4. SET uses two asymmetric key pairs: one set is used as a "key exchange" pair in the process of encrypting and decrypting messages; the second pair is used as a "signature pair" for the creation and verification of digital signatures.

         For each key pair, a SET participant has a certificate issued by a Certification Authority.

         Cardholder certificates are not required in the draft version of the specification.

         1. Purchasing with SET

1. 1. The cardholder has identified what he wants to purchase with which brand of card and communicated that to the merchant; he now requests the merchant to initiate payment with a particular brand of card.
   1. The merchant returns a transaction identifier and the merchant and payment gateway certificates for the brand of card.
   1. The cardholder software:

• • verifies the merchant and gateway certificates by traversing the trust hierarchy to the root key;
  • creates the Order Information (OI) (NOTE This is NOT the description of goods or payment terms — that has already been communicated to the merchant ) and payment Instructions (PI), including the transaction identifier and the cardholder signature certificate;
  • computes the message digest of the OI and the PI; concatenates the two digests, computes the message digest of the result and encrypts it with its private signature key, this is called "a dual signature";
  • generates a random symmetric encryption key, encrypts the PI with it, then encrypts the symmetric encryption key and the cardholder’s account number with the Payment Gateway’s key exchange public key;
  • sends to the merchant the dual signature, the message digests of the OI and PI, the OI and the encrypted PI.

1. 1. The merchant software:

• • verifies the cardholder signature certificate by traversing the trust hierarchy to the root key;
  • uses the cardholder signature public key and the message digest of the PI (sent with the OI) to check the digital signature ("dual signature") to ensure that the OI has not been tampered with and that the signature is valid;
  • generates and digitally signs a purchase response message including the merchant’s signature certificate to indicate receipt of the order; the response is then sent to the cardholder.

1. 1. The merchant can carry out payment authorisation before or after responding to the cardholder. The merchant software:

• • generates and digitally signs an authorisation request including the amount of money; encrypts it with the Payment Gateway’s key exchange public key;
  • sends the request and the PI from the cardholder to the Payment Gateway.

1. 1. The Payment Gateway:

• • decrypts both the authorisation request and the PI;
  • verifies the certificates of the merchant and cardholder;
  • checks the integrity of the PI, using the message digest of the OI, which is sent with the PI, and the "dual signature";
  • checks that the authorisation request and PI correspond;
  • sends an authorisation request to the Issuer via a card association network;
  • when a response has been received from the Issuer, the Payment Gateway generates and digitally signs an authorisation response message which is encrypted and sent to the merchant.

1. 1. The merchant generates and digitally signs a payment capture request which is encrypted and sent to the Payment Gateway.
   1. The Payment Gateway decrypts and verifies the request and sends a clearing request to the Issuer via the card association network. The Payment Gateway generates and digitally signs a capture response message which is encrypted and sent to the merchant.

1. 1. 1. Issues, status and standards

1.  
2. Projects and standards
3. This section reviews a number of projects, both longer and shorter in duration. The objective is to show which standards are being used and what new standards may be produced from these projects.
   1. General Projects
   2. 1. ICE-TEL
      2. 1. Objectives

• • secure components as a toolkit for integration with applications, where users need to be certified;
  • a large scale public key certification infrastructure in a number of European countries.

1. 1. 1. 1. Application areas

• • secure communication between administrations and electronic request and delivery of documents in the region of Turin, co-ordinated within the EU-sponsored "Information Society Network",
  • secure communication between national Computer Emergency Response Teams (CERTs) and other distributed network support groups
  • provision of a security enabled electronic Directory service for a large British research agency.

• • secure e-mail
  • secure directory access
  • secure file transfer.
  • secure use of the World Wide Web.

• • which prove the authenticity of communicating partners,
  • which protect the integrity of communication data,

1. 1. 1. 1. Certification Authority Infrastructure
         2. To meet these security requirements using public-key encryption and signature schemes, a widely distributed infrastructure for public key certification needs to be established. It is the major task of the ICE-TEL project to establish a prototype network of certification authorities (CA).

            These CAs are interrelated by mutual certificates of their public-keys. A client of any of these CAs will be able to communicate securely with any other client of any of these CAs, in that both communication partners can trust in the certified binding of their names and related public keys. There is no need to check public keys on another communication path (like the exchange of finger prints over the telephone or by exchange of business cards) before the secure communication can be made.

         3. Mail and Directory user agents, key management tools
         4. ICE-TEL will equip the users with mail and directory user agents with integrated security functions for digital signature and encryption of their data. ICE-TEL will also develop and distribute easy-to-use tools for users which allow them to communicate with their certification authorities. With these tools, users can easily maintain their encryption keys and related information, e.g., to retrieve certificates, certification paths, black lists, and all information needed to verify the public keys of other users. ICE-TEL will also equip certification authorities with management tools which allow them to maintain their information bases, to communicate securely with their clients and other certification authorities, and to exchange all information necessary for responsible key management.
         5. Securing the World Wide Web

• • restriction of access to specific WWW pages;
  • authentication of users who wish to make commercial transactions or access data on the WWW;
  • in a commercial transaction, binding commercial terms from one source (e.g. a supplier) to a user, having all parties authenticated and making the transaction confidential and non-repudiable;
  • non-repudiable pages from the WWW available to clients.

1. 1. 1. 1. Software verification
         2. The above facilities need to be provided by programs which are fully available in source form, to ensure that the security implications, and the strength of the algorithms used, can be verified.
         3. Directories
         4. ICE-TEL aims to develop a product named a Guardian DSA which will enable organisations which are concerned with privacy to connect to public directory infrastructures. The Guardian DSA will provide a secure gateway to such public structures while supporting secure (confidential and authenticated) communications for users inside the organisation.
         5. The project and standardisation
         6. The deliverable from the project entitled "Architecture and General Specifications of the Public Key Infrastructure" relates the project to a number of standardisation activities.

            The report contains a chapter on models of trust, from a completely general model of trust to a simplified "web of hierarchies" model. This chapter is planned to be submitted to the IETF-PKIX working group as an informal Internet Draft. An annex to the report was submitted to the IETF-PKIX working group as an Internet draft "Internet Public Key Infrastructure, Part III: Certificate Management Protocols".

            Other parts of the specification — the chapter on security policies that the ICE-TEL PKI will follow and the chapter on operational modes and guidelines of Certification Authorities (CAs) — could be developed and used to establish generally agreed standards for Security Policies for PKIs and Guidelines for the operation of Certification Authorities.

         7. Standards and technology used

1. 1. Electronic Commerce
   2. 1. Secure Electronic Marketplace for Europe (SEMPER)
      2. The goal of the SEMPER project, funded under the ACTS programme of the EC, is to provide open and comprehensive solutions for secure commerce over the Internet and other public communications networks. The project is for three years, September 1995 - August 1998 with a budget of 9 million ECU.

         The project has published a document entitled "Basic Services, Architecture and Design" (September 1996).

         1. The SEMPER model for electronic commerce — The players

• • users of the marketplace, that is buyers and sellers
  • third parties who enable the business between the users.

• • time-stamping
  • contract witnessing
  • long term archiving
  • fair exchange of values.

1. 1. 1. 1. Concepts in the SEMPER model

• • signed documents, such as certificates, orders, receipts
  • information, such as digital goods, a cryptographic key for enabling access to a video transmission (information is not processed as part of the transfer)
  • electronic money.

1. 1. 1. 1. SEMPER Architecture

• • the Cryptographic Services, which provide message encryption and decryption, hash functions, message authentication codes, digital signatures and key generation;
  • the Communication Services, which support communication in a network and protocol independent way
  • the Archive Services, which provide local storage of all persistent data such as digitally signed messages, certificates, cryptographic keys, transaction and evidence objects; data can also be stored securely e.g. using encryption or in tamper-resistant memory on a smart card
  • the Trusted Interactive Graphical User Interface Services provide a distinct user interface to emphasise that this and not the regular interface, such as a web-browser, is the interface, for critical inputs, e.g. account numbers, and outputs, e.g. confirmation of the seller’s identity
  • the Access Control Services, which implement access control to the various blocks of the SEMPER architecture.

1. 1. 1. 1. Trust and SEMPER
         2. In order to use SEMPER with confidence, a user must trust its design and implementation. In order to establish this trust, the SEMPER project, in its initial stages, will follow an open design process, capable of security evaluation, will digitally sign issued software and will support use of tamper-resistant hardware.
         3. Certificates in SEMPER

1. 1. 1. End-to-End Security over the Internet — E2S

• • exploring the multicultural and multicountry aspects of the architectural model for business
  • building prototype application packages on components developed elsewhere
  • user assessment and evaluation of the model
  • secure commercial and business operations over the Internet
  • development of user security policies and reference models suitable for commercial and business use.

1. 1. 1. OSM, an Open Service Model for Global Information Brokerage and Distribution

• • specification of an Open Architecture for Information Brokerage and Distribution;
  • development of a supporting implementation of that architecture;
  • validation of the architecture and implementation under public trials

• • payment and security facilities;
  • transactions and persistent asynchronous communications;
  • catalogues, and services.

1. 1. . The World Wide Web

• • Platform for Internet Content Selection (PICS)
  • Digital Signature Initiative.

1. 1. 1. PICS (Platform for Internet Content Selection)
      2. PICS represents the first specification to address this requirement, focusing on the classification of information according to its content. Implementations of this specification have concentrated on classifying information content in order to protect children from being exposed to inappropriate material. The PICS specification has been approved by the W3C as a Recommendation.

         Key concepts in the PICS specification are:

         rating service, where a third party provides content labels for information

         rating system, which specifies the criteria used in the labels, the scale of allowable values for each criterion, and a description of the criteria.

         content label, which contains the ratings for a particular document.

         If the information object is a story with pictures, PICS enables an answer to be given to the question: "Is it suitable for viewing by a nine year old child?" It thus has a similar function to the V-chip.

         PICS also specifies a means for ensuring the integrity of a page of information, using a message digest, and the authenticity of labels produced by a rating service, using a digital signature.

         PICS also defines a label bureau, where a third party can be the holder of label information about documents held on a number of servers. This service can be linked to an information broking service enabling documents to be found according to their classification.

      3. Digital Signature Initiative

• • Cryptographic Format. To define an agreed format for digital signatures for information objects on the WWW.
  • Awareness of Trust Issues. To help organisations taking part in the Digital Signature Initiative learn what the issues and problems are in the management of trust. In particular to realise the importance of a common architecture for managing trust in different application areas, such as software, product descriptions, press reports, academic reports and the value of building a reusable solution for trust management.
  • Common Trust Management Environment. The major goal is to establish a shared, industry-wide trust management infrastructure enabling users and providers to create Web wide trust policies.

• • a Digital Signature Label Architecture (see below);
  • a Trust Management Architecture, which will enable users to state their security policies with respect to information objects and process, in the most part automatically, assertions about information objects and so decide what to trust and on what basis.

• • the key holder’s identity will be expressed using a signature block, which will say who signed the information resource, when, and using what algorithms;
  • the assertions about the information will be contained in a signature label, which is an extension of the PICS label;
  • the information resources will be listed in a manifest.

1. 1. Healthcare — TrustHealth

• • A set of specifications for security services and interfaces.
  • A trusted third party service infrastructure with operational systems in some countries and publicly available specifications.

• • the PC work station will continue to be the major type of terminal
  • healthcare professionals are very mobile in their work pattern
  • control of keys and certificates makes the smart card an ideal storage medium.

• • Selection of Security Services and Interfaces — functional requirements for common security services and a specification of a TrustHealth Security Platform
  • Guidelines for Implementation of Security Services and Interfaces — detailed interface specifications and implementation guidelines
  • Functional Specification of TTP Services — functional requirements of services including Naming, Public Key and Professional Certification, Card Issuing and Directory Services.

• • a User with a name and some additional number sufficient to identify him uniquely wishes to acquire a Health Care Professional (HCP) card enabling him to access restricted services, digitally sign documents and communicate confidentially with fellow professionals;
  • he approaches a professional registration authority with a request for a HCP card;
  • the user’s identity, a distinguished name, obtained directly or indirectly from a naming authority, is registered with a public key registration authority;
  • the user then receives:
  • • from a key generator, three pairs of keys: one for digital signing, one for key encryption and one for identification and authentication. (Organisational issues might lead a local key generator to be preferred to a central key generator);
    • public key certificates (one for each key pair), generated by a public key certification authority, linking his identity to each public key;
    • an electronic professional certificate, recording his identity and his professional status, authorisations and so forth;
    • a HCP card, containing three private keys, the respective public key certificates and the professional certificate.

1. 1. Telecommunications
   2. 1. Advanced Security for PErsonal Communications Technologies — ASPeCT

• • external communication: floppy disk driver, graphical user interface, communication subsystem
  • TTP security control: database, containing keys, user information and event information (e.g. for audit); and security functions
  • TTP functions and operation: provides security services to the layer above via an application programming interface based on Generic Security Services-API and Key Management Framework- ISO/IEC 11770-1
  • cryptographic functions: provides cryptographic services to the layer above via an application programming interface based on Generic Cryptographic Services-API published by the Open Group.

• • Rivest-Shamir-Adelman (RSA) signature based on ISO/IEC 9796-2 Digital signature scheme giving message recovery - Mechanisms using a hash-function
  • Agnew-Mullin-Vanstone (AMV)-signature based on ISO/IEC 14888-3 Digital signatures with appendix - Certificate-based mechanisms.

1. 1. Electronic mail

• • directory business scenario: yellow pages will be used to locate an individual to whom a message is to be sent
  • digital signature business scenario: using S/MIME format a signed document will be sent to a customer
  • encrypted message business scenario: using S/MIME an encrypted and signed document containing a contract will be sent by a customer to a supplier.

1. 1. Electronic publishing, information broking, copyright management
   2. 1. Architecture for information Brokerage Service — ABS

• • to design, implement and validate a prototype of the broker system by conducting significant international trials;
  • to contribute to relevant standardisation activities, especially on the topics of broker/trader services, broker architecture, federation of broker systems, broker information models, particularly to support international deployment of the services;
  • to exploit the trials results in order to produce a comprehensive technical and economic evaluation of the potential market development in different business areas.

1. 1. Chip - Secure Electronic Transaction — C-SET
   2. Cartes Bancaires(CB), the French bank card association, has developed this solution, the C-SET (Chip-Secured Electronic Transaction) protocol. In the first phase, existing smart cards issued by the French banks will be used. The solution will provide security to national and international payment transactions in electronic commerce and interoperates fully with SET, which is developed by CB’s international partners Visa and MasterCard. It is identical to the generic architecture of CB remote payment, except that the connection between the cardholder and the merchant is established through an open network.
      1. Differences between C-SET and SET
      2. Security in the C-SET architecture relies on the use of the smart card with the active participation of the cardholder. The cardholder has to key in his PIN to authorise his card to sign a transaction.

         In contrast, the SET architecture, implemented entirely in software, does not support the use of a smart card. Security relies on software secure mechanisms and therefore depends on the environment in which the software executes, the cardholder’s PC. In C-SET all the sensitive sequences of the cardholder's software are executed in a trusted environment: the PIN-pad reader and the smart card.

         The integrity of the PIN-pad reader is protected, it is a Tamper Evident Device. It does not contain any secret but protects the PIN (Personal Identification Number). In C-SET, all sensitive information going through the PC (card data and payment instructions) are protected for confidentiality and integrity.

         Secret keys are kept in secure devices such as the smart card.

      3. Interoperability with SET
      4. Compatibility with SET is a major requirement, but the implementation of SET in the CB remote payment process would introduce SET weaknesses, arising from the software-only environment. Therefore, interoperability between C-SET and SET is provided by specific converters.

         A converter serving the C-SET cardholder acts on the one hand as a payment gateway (using the CB Acquirer key) to check the C-SET payment instructions, and on the other hand as a SET certification authority (using the Visa/MasterCard certification key) to grant SET certified identities to cardholders.

         A converter serving C-SET merchants acts on the one hand as a SET certification authority to grant SET certified identities to merchants, and on the other hand as a SET payment gateway to check SET payment instructions.

      5. Future plans