DigSig by xumiaomaio

VIEWS: 14 PAGES: 61

									Technical PKI interoperability in the European energy sector                                    1




                                   PKI Policy


            Recommendations to market participants




                                             Status:            Request for comments
                                             Version/release:   0.3
                                             Revision:          none
                                             Date:              June 04, 2011




ebIX                                                                             May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                         2


                                                             CONTENTS

0      MANAGEMENT SUMMARY .................................................................................................... 4
    0.1       BACKGROUND ......................................................................................................................... 4
    0.2       KEY RECOMMENDATIONS ........................................................................................................ 4
1      INTRODUCTION ......................................................................................................................... 6
    1.1       ABOUT THIS DOCUMENT .......................................................................................................... 6
    1.2       SCOPE OF PROJECT ................................................................................................................... 6
    1.3       PARTICIPANTS IN THE PROJECT ............................................................................................... 6
    1.4       REFERENCES ............................................................................................................................ 7
    1.5       CHANGE LOG ........................................................................................................................... 7
2      THE CONCEPT OF “TRUST” IN ELECTRONIC COMMUNICATION ............................ 8

3      FIELDS OF APPLICATION ..................................................................................................... 10
    3.1    INTERNET BUSINESS APPLICATIONS ..................................................................................... 10
      3.1.1    Use for Internet Applications ........................................................................................ 10
      3.1.2    Internal Applications ..................................................................................................... 10
      3.1.3    External Applications .................................................................................................... 10
    3.2    INTERNET BUSINESS SCENARIOS ........................................................................................... 10
      3.2.1    Business Partner Models in Electronic Trading ........................................................... 10
      3.2.2    Business Security and Risk ............................................................................................ 11
      3.2.3    Business Scenarios and Risk Management.................................................................... 12
      3.2.4    Risk Categories.............................................................................................................. 13
      3.2.5    Requirements for the PKI for Minimizing Business Risks ............................................. 15
    3.3    FIELD OF APPLICATION OF COMMUNICATION SECURITY ...................................................... 15
4      STRUCTURE OF THE PKI ...................................................................................................... 17
    4.1    APPLICATIONS ....................................................................................................................... 17
    4.2    CONFIDENCE MODEL ............................................................................................................. 18
    4.3    THE CERTIFICATES ................................................................................................................ 19
      4.3.1    Validity Model ............................................................................................................... 19
      4.3.2    Certificate Hierarchy .................................................................................................... 20
      4.3.3    Publishing Certificates .................................................................................................. 21
      4.3.4    Cross-Certification ........................................................................................................ 21
    4.4    TRUST CENTER SERVICE ....................................................................................................... 21
5      SMART CARD PERSONALIZATION MODEL .................................................................... 23
    5.1       PRE-PERSONALIZATION ......................................................................................................... 23
    5.2       PERSONALIZATION ................................................................................................................ 23
    5.3       INITIAL SUPPLY OF SMART CARDS DURING THE IMPLEMENTATION PHASE ......................... 23
    5.4       KEY GENERATION ON THE SMART CARD .............................................................................. 24
    5.5       POST-PERSONALIZATION ....................................................................................................... 24
6      PKI ORGANIZATION ............................................................................................................... 25
    6.1    PURPOSE AND OBJECTIVE...................................................................................................... 25
    6.2    ORGANIZATIONAL UNITS FROM AN OVERALL PERSPECTIVE ............................................... 25
    6.3    CERTIFICATION AUTHORITY ................................................................................................. 27
      6.3.1    Operational CA ............................................................................................................. 27
      6.3.2    Smart Card Management Service (Optional) ................................................................ 30
      6.3.3    Time Stamp Service ....................................................................................................... 31
    6.4    REGISTRATION AUTHORITY .................................................................................................. 31
7      CORPORATE DIRECTORY .................................................................................................... 35


ebIX                                                                                                                            May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                    3


APPENDIX A                 REQUIREMENTS IN TABLE FORM ............................................................. 37
  A.1       GENERAL REQUIREMENTS ..................................................................................................... 37
  A.2       PKI COMPONENT ORGANIZATION ......................................................................................... 37
  A.3       CREATING/STORING KEYS/CERTIFICATES ............................................................................ 37
  A.4       PROCESSING KEYS IN CLIENT SOFTWARE ............................................................................. 38
  A.5       COST ALLOCATION ................................................................................................................ 38
APPENDIX B                 SUMMARY OF REQUIREMENTS FOR PERSONALIZATION ................ 40
  B.1   CENTRAL CARD INITIALIZATION (PRE-PERSONALIZATION) ................................................. 40
  B.2   SENDING THE INITIALIZED CARDS TO THE LRAS (WHERE APPROPRIATE WITH THE
  TRANSPORT PINS) ............................................................................................................................. 40
  B.3   CARD PERSONALIZATION AT AN LRA................................................................................... 40
  B.4   AUTOMATIC ACTIVITIES AT THE CA DUE TO CARD PERSONALIZATION (WITHOUT
  INTERVENTION OF A CA OPERATOR) ................................................................................................ 40
  B.5   CARD APPLICATION PROCEDURE .......................................................................................... 40
APPENDIX C                 SUMMARY OF REQUIREMENTS FOR DIRECTORY/REPOSITORY ... 42
  C.1       REQUIREMENTS REGARDING VALIDATION ........................................................................... 42
  C.2       SOLUTION PROPOSAL ............................................................................................................ 42
  C.3       OTHER ASPECTS .................................................................................................................... 42
APPENDIX D                 NOTE ON POST-PERSONALIZATION ......................................................... 44

APPENDIX E                 GLOSSARY ......................................................................................................... 46




ebIX                                                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                                 4


0 MANAGEMENT SUMMARY
This document is the sixth in a series of publications from the ebIX project “DigSig” regarding the use
of encryption and digital signatures within the European energy sector. Being defined in a general
manner, the organizational parts aim at ensuring a uniform organizational security level with regard to
electronic signature and encryption of transactions between market participants across company
boundaries.

The technical parts of the documents, defined as well in a general manner, are to ensure interoper-
ability at a technical level even where different products or services are utilized. The political,
organizational and technical statements represent recommendations which are to enable a reliable
trustworthy infrastructure to be set up among market participants along the lines of solidarity.

These measures shall serve as a guide for implementation within companies and for subsequent
application at market interfaces. However, procedures other than proposed in the recommendations
need to be justifiable and must not impair the general level of security.

For economic reasons, market participants should be interested in making sure that the infrastructure
of confidence is not undermined. This is the only way to guarantee secure handling of electronic
business in the medium term, and to ensure that further automation steps can be managed in the light
of future developments.

0.1    Background

The security policy of a jointly, albeit in certain cases only partially, used organizational and technical
platform is a matter that affects all market participants who wish to use this platform. Market
participants who decide in favor of an external certification service provider, however, will be
responsible for significantly fewer issues because the chosen, generally recognized Trust Center1
assumes responsibility for the majority of services performed. Refer to the document “Management of
key material”.

The recommendations of this entire document are relevant for market participants who aim to
implement either a complete or extensive parts of a MAKE solution; in other words, participants who
wish to set up their own Public Key Infrastructure which other participants must be able to trust. Due
to the increasing extent to which standard software (for example, Microsoft) supports certificate-based
security functions, it is likely that even small companies will be more willing to use these components
to create their own PKI.

0.2    Key recommendations

Alongside the general political conditions manifested in the form of a joint declaration between the
associations, it is imperative that market participants agree upon a uniform level of security at the
interfaces to their communication relationships, which are protected by PKI mechanisms.

In addition to political provisions (for example, self-commitment), comparable technical and
organizational security must be ensured for data that is processed by comparable applications. This
applies, in particular, to Electronic Data Interchange relationships (EDI) and the associated EDI
converters, as well as e-mail exchange between the partners (with file attachments) who are already
involved in the joint Public Key Infrastructure.

The aim of the “Security policy for setting up and operating cross-association Public Key
Infrastructures” is to support a cross-industry security infrastructure.
1
  Certificates can be obtained from any Trust Center (MAKE or BUY, accredited or non-accredited) providing
they conform to ebIX recommendations (for example, Certificate Policy).


ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                             5



Other conceptual bodies of rules and regulations, which ensure a consistently high level of security
and interoperability, are the Certification Practice Statement and Certification Policy (CP). The CP
should be created by each company separately in line with the respective application landscape.

It is not important here that each market participant involved in the procedure deploys the same
technical components or adopts the same organizational approach.

Nevertheless, the purpose of this document on the PKI security policy is to establish a necessary
minimum of

   joint concepts and their definition
   joint services and
   joint organizational forms

for the joint communication interfaces. Only then is it possible to set up and operate a jointly used
infrastructure of trust.




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                               6


1 INTRODUCTION
1.1    About this document

Within the European energy sector, electronic data interchange (EDI) using a variety of methods has
become a core business enabler over the last few years. It is no longer possible to imagine how
liberalised energy markets would function without EDI; rapid and automatic interchange and
processing of business transactions, as far as possible without human intervention, is organisationally
and economically necessary for all participants at all levels. Whether the transactions contain metering
data, invoices, customer switching information or schedules: automation brings benefits through
process optimisation. Nevertheless, there are further, fundamental considerations – political,
organisational and technical – to bear in mind, which influence implementation.

Core processes with a high-volume character require supporting processes within the organisation.
Securing EDI transactions is one such supporting process, especially in connection with transparency
and integrity of the data involved. Just as a signature gives a piece of paper legal character – e. g. from
an offer to a contract – EDI requires the same legal status for security and non-repudiation. To this
end, it is essential that a secure business partner network be established, within which electronic
business transactions for all participants are made possible. Therefore we need to promote an
infrastructure which can be trusted both by larger corporations (with their own certification
authorities) and smaller companies (who buy-in from service providers).

This can only be guaranteed by verification and confidentiality mechanisms directly associated with
the information exchanged. These mechanisms need to cover the whole range of the logical
transactions consistently. This is necessary to be able to carry out transactions in the new deregulated
market between market participants in a legally correct and clear-cut manner in terms of liability law,
and not least in an inexpensive way under technical and organisational aspects.

1.2    Scope of project

In the light of these requirements, a small project (“DigSig”) was established within the ebIX structure
to generate appropriate documentation which can then be used as a basis for implementation scenarios
on a national and/or international level. The intention is to describe the overall harmonisation
requirements for the use of encryption and digital signatures for electronic transactions within the
European energy sector; also being compatible with the following overall ebIX objectives:

1) Make recommendations of common procedures that facilitate the common open European energy
   market
2) Make common standards for secure data interchange that can automate the process to reduce the
   costs for the parties involved.

1.3    Participants in the project

The project is based on documents produced within the German national group (under the able
tutoring of Dr. Willi Kafitz, Siemens AG, Frankfurt) and has been coordinated for ebIX by Carl W.
Major. The following participants provided intellectual and/or financial support to the project:




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                7



Country         Name                                      Company
DE              Carl W. Major                             E.ON Netz
DE              Dr. Konstantin Staschus                   VDN
DK              Erik Hartwell                             Energinet.dk
BE              Hugo Dekeyser                             Eandis
SE              Joachim Abrahmsén                         Steria
NL              Lodewijk ter Haar                         Tennet
FI              Matti Vasara                              Fingrid
NO              Per M. Breistein                          Statkraft
NO              Ole Jacob Høyland                         Statnett
SE              Oscar Ludwigs                             Svenska Kraftnät
SE              Robert Lundin                             Steria
CH              Rudolf Baumann                            ETRANS

1.4     References

[1] Original project proposal, see http://www.ebix.org/

1.5     Change log

 Ver.    Rel.   Rev.   Date               Changes
 0       1      none   2006-01-26         Document generated
 0       2      none   2006-02-28         Comments incorporated
 0       3      none   2006-05-16         Published as ebIX RFC




ebIX                                                                         May 16, 2006
Technical PKI interoperability in the European energy sector                                                8



2 THE CONCEPT OF “TRUST” IN ELECTRONIC COMMUNICATION
Trust is an important prerequisite for conducting business via open networks. Questions crucial to this
concept include:

   Am I sure about who I am dealing with?
   Is the business conducted of a binding nature, that is, are the declarations of intent of my business
    partner unambiguous and indisputable?
   In the event of a dispute regarding the services provided, can I assert my claims?
   Are my communication facilities secure and do they ensure confidentiality?

One of the requirements for the more widespread use or implementation of a business-oriented
security platform for cross-company business processes via open networks is fulfilled within the scope
of the PKI project. A Public Key Infrastructure is used for this purpose.

A Public Key Infrastructure is defined as follows:

“A system of components, services, processes and operators for creating, disseminating and managing
keys and certificates”.

These are a prerequisite for secure services for communicating via Internet-protocol-based networks.
Secure services enable

          the authenticity of electronic documents to be verified,
          the identity of communication partners to be verified,
          confidentiality to be maintained,
          information exchange that has taken place between known partners or network components
        to be verified (time related).

The essence and purpose of a PKI are always the same irrespective of whether it is an individual
company PKI or a secure Business Partner Network. A joint set of rules and regulations is always
required for all participants in cases where bilateral or multilateral business relationships are
concerned. Only when it comes to technical verifiability (validation) does the situation inevitably
become more complex. These interdependencies are dealt with in greater detail in other documents
(for example, in the Certification Practice Statement and Certification Policy).
PKI services are, therefore, at the disposal of two extensive fields of application:
(1) The application field for network security and
(2) The application field for business security/information security
The focus here will be on the second field of application, with attention also being paid to underlying
transport security. Asymmetric cryptographic methods are nowadays commonly used for transport-
bound security too (in particular for encryption). These methods do not initially have to be linked with
the person-related Public Key Infrastructure, however, because the products available on the market
include their own key generation and management mechanisms. The following merely contains
information on server certificates, for example.

The PKI comprises the following service components:

   Trust Center service
    Includes the following functions: key generation, certificate creation, key archiving, time stamp
    service.
   Directory service
    Includes the following functions: certificate and CRL service.


ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                               9


   Key issue service
    Includes the following functions: user identification, application, creation, certification request,
    key issue and management.
   Smart card service
    Includes the following functions: smart card personalization and smart card management.

Three principal tasks must be performed for the application fields:

   Supply users with key material and certificates,
   Supply the applications, computers, processes with certificates and test data (directory service
    with CRLs, for example),
   Provide a trustworthy time stamp service (optional).

The PKI is an important security-related requirement for the companies involved in the procedure to
enable trustworthy communication to take place across open networks. The PKI provides methods and
techniques that enable business transactions to be carried out across open networks with a level of
trustworthiness that fulfills the requirements of the business being conducted. The PKI should be
based on international standards and reflect a level of security that is necessary for trustworthy
business processes. The PKI is all the more important the greater the extent to which the business
processes are converted to Internet-based applications and further developed (portals).

From an overall company perspective, the PKI serves two primary purposes:

   It helps streamline operational processes
   It is a prerequisite for B2B business relationships based on mutual trust.

Within the meaning of the ebIX PKI Policy, the first point defines the motivation to act; the second
point is relevant for the purpose of standardizing joint security criteria.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                             10



3 FIELDS OF APPLICATION
3.1     Internet Business Applications

The field of application of the PKI includes e-mail, the interchange formats (EDIFACT, XML, CSV)
and all other applications that exchange sensitive information via bilateral or multilateral network
relationships between the partners.

The Internet is synonymous with an open network. It is not important here whether the network type
used as a basis for communication between market participants is in fact the Internet. What is
important is that we are dealing with a network that is open or that the requirements regarding liability
and confidentiality cannot be verified by (one of) the communication partners.

3.1.1    Use for Internet Applications

Internet technology is becoming more and more widespread. On the one hand, it offers enormous
scope for standardizing and cutting the cost of networks as compared with vendor-specific
technologies; on the other hand, it acts as a global information hub via which anyone can choose to
communicate with anyone anywhere in the world, just in the same way as using a telephone.


3.1.2    Internal Applications

Internet technology is also deployed in company intranets because these generally use the services and
equipment of public network providers. It is, therefore, advisable for these internal applications to be
supported by the PKI insofar as general, i.e. cross-company, security issues are affected directly or
indirectly. The main business benefits to be derived from this include reduced costs and protection for
sensitive company data. The security requirements should be equally stringent in all areas that affect
multilateral business processes (analogy of the weakest link).


3.1.3    External Applications

The Internet can be used to handle business transactions with known business partners and
communication with external employees as well as to establish contact with new partners and
customers.

In the first case, this involves the procedures agreed upon in the interfaces of the electricity market for
exchanging (sometimes highly sensitive) data with registered companies or persons. The PKI has the
task of establishing a basis for secure and trustworthy connections by means of certified keys.

Stringent security requirements for electronic transactions have, for example, been developed by the
stock exchange.

3.2     Internet Business Scenarios


3.2.1    Business Partner Models in Electronic Trading

Catchwords are often used for applications, for example, electronic trading, e-commerce, e-business,
e-government, and so on, depending on the application or business relationship in question.

The following typology has already become established:


ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                          11



   Business-to-Consumer, or B2C
   Business-to-Business, or B2B
   Citizen-to-Government, or C2Gov, A
   Business-to-Employee, or B2E

This document only discusses B2B relationships.


3.2.2   Business Security and Risk

The term business security is used here to mean safeguarding against business-related risks. Business
risks are usually assessed in terms of money.

The security of a business relationship is, therefore, based on two cornerstones:

   Ensuring the confidentiality and authenticity of the business information (this also applies
    to orders for financial transactions)
   The reliability of the declarations of intent of the partners and their authenticity (this
    includes trustworthiness from an economic point of view)

Absolute certainty must prevail regarding the person with whom the business transaction has been
agreed upon and is conducted. Today‟s business practices and their strong emphasis on interpersonal
communication and human supervision make these business risks seem rather unlikely. The objective
here, however, is to harness available scope for rationalization by transferring at least some of the
human mechanisms for supervision and for establishing confidence and trust to a certificate-based
infrastructure of trust (enabler for e-business).

Business security is safeguarded by the conventions of civil and commercial law. Further legal general
conditions are currently being defined for Internet business transactions. The “electronic signature” for
documents that are communicated electronically is equivalent to a declaration of intent with a manual
signature. The appropriate sets of rules and regulations (EU guidelines for electronic signatures,
German Digital Signature Act, U.S. Law for Electronic Signatures, and so on) are already in force. A
prerequisite for legally binding electronic signatures is a PKI.

The business security objectives can be seen in the following table.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                          12




              Security Aims for Electronic Business

         Unique identification of business partners
                                                                         Authenticity
         Integrity of information/data transferred

         Confidentiality of information transferred                      Encryption

                             m
         Verifiability of com nuication                                  Liability


         Business transactions with elec. signatures must have evidentiary value




Many business portals, EDI systems or trading platforms currently available on the market use Internet
security protocols. In the critical area of minimizing business risks at information level, the required
security measures (for example, verification of personal declarations of intent of the business partners)
are now laid down in the law. Using the PKI in accordance with joint criteria will help achieve the
required level of security and facilitate system management.


3.2.3   Business Scenarios and Risk Management

Business agreements do not usually require a specific form. Contracts that are concluded verbally are
the norm for most day-to-day business activities. Bigger business deals that involve much greater
financial risk are normally documented, that is, quotations, conclusion of the transaction, confirmation
of the delivery, and payment orders must be made in written form. Providing these documents in
written form with signed declarations of intent of the business partners is, therefore, normal business
practice. Even if the interchange formats for the electricity industry have already been created, the
security measures implemented should provide a basis for using electronic applications further (for
example, contracts). Measures for assessing business risks objectively, which will then be reflected in
credit security arrangements, supply of equity and so on, are currently being defined on an
international scale (Basel II) and laid down in national law (this will take place during the course of
2005). Great importance will be attached to the formalized assessment of "operational risks" due to the
crucial role played by electronic data processing with a view to securing the success of the company.

In electronic business transactions, written documents and declarations of intent must be replaced by
electronic files with personal, electronic declarations of intent. The purpose of this document is merely
to define a framework within which risk management for contracts in electronic form function in the
same way as for contracts in written form. It should be pointed out once again that an increase in
throughput makes greater demands on B2B processes with regard to security and liability. The
German electricity industry alone deals with approximately 2.5 billion formatted B2B transactions
every year, which can be processed via the formatted interfaces of the electricity market. To increase
acceptance with a view to leveraging the full potential involved, powerful PKI mechanisms must be
provided in order to achieve a similar level of efficiency with an automated infrastructure of trust.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                              13


3.2.4   Risk Categories

A distinction is made between three risk categories for business transactions in the electricity industry,
namely a low, a medium and a high risk category. The transitions between these categories are fluid
and differ from one company to the next.

The low risk category covers business deals with a low contractual value per business transaction. This
means that individual bad debt losses in the electricity industry do not represent an economic threat to
the company. Bad debt losses with relatively low values can, however, become critical for electricity
utilities if it becomes known that the company does not sue for the recovery of a low-value debt
because furnishing proof for a legitimate claim is more time consuming and costly than the value of
the business transaction itself.

In the electricity industry, high-value business deals or transactions (for which special safeguarding
measures are required for legal reasons) that are carried out via the Internet or open networks should
be classified in the high risk category.

The category between the low and high categories is less clear cut and can be defined by each
company in line with the nature of its business dealings.

If business transactions are to be carried out without encryption via the Internet, it is relatively easy for
unauthorized persons to gain access to confidential information. Such a loss in confidence and trust
can severely damage the reputation and business opportunities of a company. A loss of trust and
confidence can also result in extremely high business risks. Confidentiality is, therefore, something
that should be aspired to by market participants in the interests of security.




          3 Categories of Business Risk


             Low Risk                   Medium Risk                       High Risk

             E-mail *                   E-mail                            E-mail
             Information,
                                        Business with                     Business
             Quot.                      partners based on                 with unknown
             Technical info.            contracts or with                 partners or with high
             etc.                       limited value                     or limited value
             B2B with
             low-value                                                    In legally necessary
             contract content                                             technical processes
                                                                          (official processes)
              *) Depending on the content, e-mail can appear in all three categories



The three categories of business risk are portrayed in the following table.

Typical methods are those with which claims from business transactions in the three risk categories
are dealt with. The overview on the following page illustrates this more clearly.



ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                              14




       Risk Management in the 3 Scenarios


            Low Risk                  Medium Risk                      High Risk

            Claims                    Claims                           Claims
            settled through           settled through                  settled through
            goodwill                  mutual agreement                 judicial decision or
                                      or out-of-court                  arbitral award
                                      settlement




       The purpose of laws regulating digital signatures is to recognize electronic
       agreements. They therefore support business risk management.




In the low risk category, claims are usually dealt with as cases of goodwill. PKI services would not be
necessary here because no costly and complex arbitration procedures are used due to the low value of
the transactions involved. In this risk category, the focus is on confidentiality and integrity of
communication, which can be ensured by means of Internet security protocols.

Note:
In line with the Basel II requirements, financial institutions will, in future, have to consider the credit
risks of their customers in much greater detail than they had been required to do to date. The
customers concerned will, in turn, have to observe these more detailed criteria in order to furnish their
lenders or shareholders with the appropriate evidence.

Alongside business-related risks, operational risks, which include telecommunications and information
technology, must also be considered. In line with this, attention has been paid to the increasing
importance of the technical side of electronic business, the reliability of which is, no doubt, critical to
the company.

Risk assessments in IT business processes and implementing suitable security infrastructures render
operational risks easier to control and, at the same time, boost the financial strength of a company in
line with Basel II.

The Law on Control and Transparency in Business (KonTraG), which came into force in May 1998,
obliges management to implement suitable risk management measures and stipulates that the
executive board member or manager responsible shall be personally liable for damage or loss caused
by negligence.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                            15


3.2.5    Requirements for the PKI for Minimizing Business Risks

The three business category risks result in different requirements regarding the PKI services.

As far as the low risk category is concerned, the existing Internet security protocols would be
sufficient.

In the case of the medium risk category, the business partners could agree upon the level of
trustworthiness required.

In the high risk category, electronic signatures that comply with the stipulations of the law are
required.

In most of the other business relationships, the use of qualified, electronic signatures is not necessary.
If a high level of security is to be achieved for signatures irrespective of legal requirements, the key
material should be stored on secure hardware (smart card).

The management responsible for business operations requires the PKI to maintain the trustworthiness
of electronic business and that no increased risks (for example, regarding claims) result from using
electronic business processes. For this reason, the distinction according to risk categories discussed
above is hardly relevant with regard to day-to-day business activities, but should be considered in a
suitable form (insurance law, assessments for loans, Law on Control and Transparency in Business,
and so on).

3.3     Field of Application of Communication Security

Confidentiality is required for business transactions with external or internal partners and internal
administrative procedures. The Internet is an unsecure medium. Practically no other means of
communication has been paid so little attention regarding the issue of security during the initial
development stages as the Internet. The Internet committees have for some years been pushing ahead
with work on the agreements for security protocols for the Internet. Confidentiality and integrity at the
transport level can be ensured by the “Secure Socket Layer” (SSL) protocol or HTTP-S for Web
applications. The “IPSec” protocol is now also popular for setting up virtual company networks via the
public Internet.

These security protocols have the following in common:

1. They are based on the layer model of the Internet. This means that the security mechanisms are
   active from the end user workstation right through to the end-user workstation of the partner or
   data server of the process and include the intermediate switching computers (communication
   servers). End users (at their respective workstations) can also be integrated personally through the
   use of smart cards for supporting cryptographic authentication.
2. They use asymmetric, cryptographic mechanisms for authentication and for exchanging
   communication keys. Suitable key material and certificates are required for the cryptographic,
   asymmetric mechanisms.

Using secure Internet security protocols (SSL/TLS) also increases technical security.

The PKI can issue key material and, where appropriate, certificates for services and other devices. The
procedures for distributing and managing this key material and certificates differ from those for
distributing and managing personal key material and certificates. This must be defined separately in
the operating concept if these options are to be included. Broadening the range of certificate-based
services is a welcome move within the scope of the cross-association PKI providing the security level
of user certificates is not compromised as a result. The following sections cover all the different types



ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                           16


of key even if the requirements for market participants specified in the declaration refer to holder
(user) certificates only.




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                          17



4 STRUCTURE OF THE PKI
4.1     Applications

The PKI supports:

     personal users (encryption, authentication, and signature keys as well as certificates) that use
      asymmetric, cryptographic mechanisms for encryption, identification, authentication and/or
      signing purposes
     processes, applications, servers and other hardware and software components that use asymmetric,
      cryptographic mechanisms for encryption, identification, authentication and/or signing purposes
     key management entities, that is, equipment and services for assigning, distributing and managing
      key material and certificates correctly in the PKI system
     the creation, distribution and management of smart cards for storing key material and certificates
      for personal users.



               Certificate Types in the Applications


                        Natural                           om
                                                         C munication
                        persons                           components


                       hold                                hold


                         User                              om
                                                          C ponent
                          certifi-                           certifi-
                          cates                              cates




Users can be natural persons and should, therefore, be referred to as holders of keys and certificates so
that they can be distinguished more clearly. Natural persons apply for and own holder (user)
certificates.

Users can also be network components and processes.

As a result, this machine-related, non-personal type of usage should be referred to as the field of
application of the communication components. These components are equipped with keys and
certificates. Communication components own component certificates.

Key material and certificates should only be issued to a holder if the person in question has been
uniquely identified beforehand. Identification is carried out by a registration authority. Companies can
set up their own registration authorities at their respective locations within the framework of the PKI
so that they have these services on site.2


2
    For network components, key management depends on the procedure or process in question.


ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                                     18


The holders are supplied with the key material and certificates in the form of a secure data carrier
called the Personal Security Environment, or PSE for short. The file contents can be issued in the form
of software or stored on secure hardware (smart card, hardware security module, HSM), and handed
over to the holder.

In the PKI, three asymmetric key pairs can be created and managed for each holder together with the
associated certificates and three different PSEs:

     Encryption PSE for encryption purposes,
     Authentication PSE for identification and authentication purposes,
     Signature PSE, only for electronic signatures.

In the case of large implementations, authentication and signatures can be handled, if necessary, with
one key. This allows archiving of the encryption key for the purposes of data recovery, should the
need arise, in particular within larger organizations (some implementations nevertheless prefer to
combine authentication and encryption in one key; although this is possible and can, in the short term,
seem simpler this can lead to organizational difficulties later, especially when data recovery becomes
necessary).

The private decryption keys can be stored on a smart card or made available in the form of a soft PSE.
Due to the fact that the requirements regarding liability generally result in specific security
requirements for signature keys, these aspects of a PKI will be dealt with more closely in this
document. Certain aspects (for example, content security) can even render local decryption
inadvisable.

The keys for encryption PSEs can be archived in the Trust Center. Authentication and signature keys
should not be archived externally. Other technical keys required (for example, for the batch process of
the smart cards in the initialization phase, for the administration or PIN change terminal if the user has
forgotten all of his personal access codes, and so on) are not discussed here. They can harbor
considerable power and are, therefore, prone to attack, which means that they must be protected
accordingly both from a technical and organizational perspective.

Other non-personal, machine-related keys and certificates (for example, for special devices, processes,
network components, SELMA) can also be generated in the PKI and distributed in accordance with
the requirements of the applications and managed in the same way as the component certificates.

4.2     Confidence Model

Certificates are a means of confirming that users (persons or components) and keys belong together
and form the basis of the confidence and trust established between communication partners. For this
reason, the certificates must be mutually recognized by the communication partners. This can be
achieved by means of bilateral agreements or, as is the aim here, by means of global recognition of the
certificates within a self-contained user group that have been issued by the certification authorities
concerned. In the first case, an appropriate bilateral agreement must be concluded between the
communication partners. In the second case, cross-certification must be carried out between the
certification authorities concerned3. The objective here is to reach as few bilateral agreements and as
many multilateral agreements as possible within the framework of the joint declaration between the
associations and its follow-up documents. The concept should, however, be sufficiently open to allow
special relationships between the market participants to be integrated without violating the generally
desired security level.

3
  Preference is now given to what are known as bridge concepts. These concepts do away with the need for
cross-certification, which is difficult to implement from an IT perspective, in favor of notification by means of e-
mail to the procedure that issued the request. The e-mail then merely confirms that the certificate in question is
trustworthy.


ebIX                                                                                              May 16, 2006
Technical PKI interoperability in the European energy sector                                                19



In a multilevel hierarchy, the certification authority itself must possess a certificate from a higher-level
certification authority, which acts as a guarantor for its trustworthiness. This chain of dependencies
ends at the respective root entity (root CA), the trustworthiness of which is inherent. Individual
companies create such a root entity themselves which can be trusted by the other partners when the
security level matches the generally defined level. The root CA as the uppermost root entity of one or
more CAs simplifies organizational changes in a PKI (for example, integration or spin-off of parts of a
company). This advantage outweighs the extra costs involved in an additional license for the CA
product.

„In Germany, a certification authority can undergo voluntary accreditation in accordance with section
17, paragraph 1 of the Digital Signature Act. It must be issued with a certificate by the German root
entity of the regulatory authority for telecommunications in Mainz4. Suitable stipulations must also be
made for mutual, cross-enterprise validation of association members. With the MAKE variant, cross-
certification can be carried out by a technical CA (hub CA) and/or one or more certification service
providers can assume responsibility for this task (BUY variant).

The overall PKI confidence model is based on:

      the intention of the PKI operators to proceed accordingly with a view to fulfilling the security
       requirements and preventing any security risks,
      the verifiability and monitorability of activities and responsibilities (security concept, operational
       procedures and standing instructions),
      regular supervision and unannounced inspections carried out by the internal auditing division.

Special protection must be provided against any form of attack for all technical components and
communication channels in the PKI. The certificates themselves are not confidential. The directories,
however, do require special protection against manipulation and denial of service.

4.3      The Certificates

The following types of certificate are used in the PKI:

      Operational CA certificate
       The operational CA certificate is created once before operations start up. Its purpose is to certify
       the operational CA (self-certification without root or certified by the root CA).
      Holder (user) certificate
       Holder (user) certificates are only issued for natural persons.
      Component certificate
       Component certificates are only issued for network components, processes, and devices. They are
       non personal and are used for network security or for SELMA, for example.


4.3.1 Validity Model
The validity model described below only applies to owner (user) certificates. Network certificates
have specific periods of validity that are determined by the respective process or by the person
responsible for network security.

4.3.1.1      Absolute Maximum Validity

Asymmetric, cryptographic keys age. Their security depends on the level of computing power
attained. The higher the level of computing power deployed to crack the key, the more likely it is that

4
    The German root entity “RegTP-Root” is the highest certification entity.


ebIX                                                                                          May 16, 2006
Technical PKI interoperability in the European energy sector                                                  20


the key will be compromised. This is why for example the validity of certificates is limited by the
current German Digital Signature Act. Key material and certificates must be renewed at regular
intervals to ensure that they are secure.

The German Federal Gazette publishes the algorithms and key lengths for the algorithms, which
according to the Digital Signature Act are regarded as secure. The validity periods of the certificates
are, therefore, limited until the end of 2004. The longer keys of the Trust Center CA are valid until the
end of 20075.

4.3.1.2    Relative Maximum Validity

Two interpretation models are used for the validity of a certificate.

 (1) In accordance with RFC 1422, the validity of a certificate that has been issued depends on the
validity of the certification path.

In accordance with RFC 1422, a certificate is valid at a defined point in time if:

   the holder (user) certificate is valid, and
   the certificate of the issuing certification authority is valid, and
   all certificates in the path through to the root entity are valid.

(2) In accordance with the German ISIS specification6 (Industrial Specification for an Interoperability
Standard), a certificate that has been issued is valid if:

   the holder (user) certificate is valid and if the signing CA was in possession of a valid certificate at
    the time the holder (user) certificate was created.
   if the certificate of the operational CA expires earlier of it is revoked, the holder (owner)
    certificates issued before this remain valid until the end of their defined validity period7.

In situations dictated by corporate policy (for example, spin-offs), the holder (user) certificates should
be revoked and re-issued if the old certificates are the responsibility of majority shareholders.
It is expected that an international agreement on RFC 1422 will be reached by the time the ebIX PKI
is put into operation regarding the validity model to be used.

4.3.2     Certificate Hierarchy

The certificate hierarchy within the individual PKIs of the market participants should contain no more
than three levels (often referred to as a two-level hierarchy (similarly structured)). It refers to
certificates at the following levels:

    Root entity
    Operational CA certificates
    Holder (user) certificates and network certificates/component certificates.

The certificate with the public key of the root entity is a self-certified certificate.

5
  These intervals are based on the announcement in the German Federal Gazette no. 213, page 18.638. If
algorithms other than the recommended ones are used in the PKI, the validity period must be specified
accordingly by the CIO.
6
  The German ISIS specification was elaborated as part of the SigI specifications (publ.: BSI, specification for
developing interoperable procedures and components according to the Digital Signature Act/Signature
Ordinance). The SigI and ISIS specifications ensure that international interoperability is achieved.
7
  From a technical perspective: shell model versus chain model with consequences for vertical interoperability in
accordance with the declaration.


ebIX                                                                                            May 16, 2006
Technical PKI interoperability in the European energy sector                                                 21



As with the namespace (for example, based on EAN code numbers), this hierarchy should be
implemented by the individual companies.

Several certificates can be created for the operational CA before the PKI is put into operation. If
several certificates are made available to the operational CA, virtual operational CAs can be set up8.

If, during operation, it appears necessary to set up further CAs for companies within the group, these
CAs must be subordinate to the root entity and must conclude an agreement with it. In this agreement,
the operators must declare that they will maintain the same level of security as for the operational
CAs. Adherence to these rules and regulations must be ensured for all market participants as defined
within the general scope of overall responsibility.


4.3.3 Publishing Certificates
All holder (user) certificates used for encryption and, but only where appropriate, for authentication
purposes are published in the corporate directory or repository9; signature certificates are not published
until the owner has given his permission. The certificates in the corporate directory that concern B2B
must be accessible to the entire cross-association PKI user group. Experience has shown that sub-
differentiation (who communicates with whom) is not possible and is not consistent with the
confidence model.

Network certificates are only published in the corporate directory/repository if this is necessary for the
associated application.


4.3.4    Cross-Certification

The operational CA can cross-certify with other certification authorities for the purpose of using
certificates beyond the borders of the company PKI. Cross-certification is a commonly-used method
that allows certification authorities to trust and use the certificates of other certification authorities.
The EBIX PKI is a group of company PKIs including public certification service providers whose
validation models are safeguarded by means of cross-certification. The architecture for this is yet to be
defined.

Before cross-certification is carried out, the respective security concepts and Certificate Practice
Statements (CPS) of the other certification authorities must be checked to ensure that the desired level
of security is maintained. Cross-certification must be approved by the CIO. In line with the planned
Business Partner Network in the electricity industry, the internal binding organizational and technical
rules and regulations – insofar as these affect B2B communication relationships – are to be published
in such a way that all market participants involved in the procedure can inspect the rules and
regulations of other participants. Unilateral cross-certification should not be possible.

4.4     Trust Center Service

The Trust Center service is either set up as an internal company service (MAKE) or the services of a
generally accepted certification service provider are engaged (BUY). The CIO is responsible for the


8
  A “virtual” CA is not an independent service component. The certification authority can use several keys and
certificates in order to supply different fields of application with different certificates. In addition to this
flexibility, a further benefit can be identified. If a particular operational CA signature key is compromised, a
non-compromised key together with the associated certificate can be used instead.
9
  Network certificates do not normally need to be published. The procedures concerned usually store the network
certificates in their applications.


ebIX                                                                                           May 16, 2006
Technical PKI interoperability in the European energy sector                                                22


Trust Center10. The internal Trust Center service is provided by the operational CA together with the
registration authorities.

The Trust Center service performs the following tasks:
 Creates encryption keys centrally and ensures that they are kept in a secure location and can be
   restored.
 Creates authentication and signature keys centrally (the service is, however, not responsible for
   keeping these keys in a secure location).
 Issues and revokes certificates.
 Publishes certificates.
 Designs the processes and communication interfaces to the local registration authorities.
 Carries out cross-certification with other CAs.




10
     The organizational and process structure must be described in the section "PKI Organization“.


ebIX                                                                                             May 16, 2006
Technical PKI interoperability in the European energy sector                                                      23



5 SMART CARD PERSONALIZATION MODEL
Key material, certificates and the storage media for preserving these must be personalized.
Personalization means being able to uniquely identify the holders or users of key material and
certificates.

Smart cards are used for storing holder (user) key material and certificates for Digital Signature Act
certificates and for security levels classified as high or medium.

The smart cards are obtained from the manufacturer and can, if required, be equipped with all static as
well as optical and electronic features (these are valid for all cards). The tasks to be performed by the
card manufacturer and those to be performed in the PKI will, assuming a common level of security
and interoperability, depend on a number of economic aspects and can be decided upon by the market
participant.

The personalization model incorporates the distribution and management process for key material and
certificates on smart cards. The personalization model generally comprises two levels, namely the pre-
personalization level and the personalization level itself.

5.1    Pre-Personalization

The smart cards are prepared by the certification authority. The smart cards are loaded11 with the
asymmetric key pairs from a pregenerated pool of keys or using keys that are generated on an ad-hoc
basis, and are sent to the registration authorities as pre-personalized keys in large batches in line with
plannable local requirements. The cards are then stored in a secure location. This applies in particular
to encryption and authentication keys. Alternatively, a method that is becoming more and more
common involves the signature key pair being generated on the card itself. This means that the
personal key is never separated from the highly secure card.

5.2    Personalization

The personalization process for the individual cards is carried out in the local registration authority
(LRA) in the presence of the holder12. A certificate request is sent to the operational CA where the
certificates for the users are created and then returned to the smart card at the registration authority.
The CA also sends a letter containing the PIN directly to the user. The user is identified at the
registration authority and the smart card is issued in accordance with the requirements of the Digital
Signature Act (unique assignment of the signature key to a natural person). An important prerequisite
for using a smart card is possession of the card and receipt of the letter containing the PIN.

If the smart card is to be used as a multifunctional plant ID card, it must be configured so that it can
accommodate additional information regarding plant security, and so on. The contactless chip (for
example, “Legic” or “Mifare”) on the plant ID card must also be personalized. The personalization
process is performed in one single step. This ensures that the holder data is consistent.

5.3    Initial Supply of Smart Cards During the Implementation Phase

If large quantities13 of smart cards are to be personalized at once for the initial supply of cards at the
individual locations, the procedure is as follows:

11
   The cards do not have to be pre-loaded with key material. Key material can also be generated on the smart
cards locally by the registration authority.
12
   If a large number of smart cards have to be personalized, this can be carried out centrally by means of batch
processing. The cards are then issued to the user ready personalized. PIN letters are sent to the users separately.
13
   For example, batches of more than 10,000 cards.


ebIX                                                                                               May 16, 2006
Technical PKI interoperability in the European energy sector                                            24



The cards are initialized and personalized with all the holder-specific data centrally. The key material
and certificates are then created. In order to prevent misuse, the cards are handed over to the local
registration authority using a secure means. The holders collect their cards from the LRA. During this
process, the holders are identified personally. The PIN letters are delivered by means of a different
trustworthy channel.

5.4    Key Generation on the Smart Card

If signature keys are to be generated locally on the smart card and certified centrally, the procedure is
basically the same with the exception that key generation must be initiated before certification is
carried out. The public key is exported via a secure channel and certified by the CA. PKCS#10
Request has proven suitable as a protocol for this purpose.

5.5    Post-Personalization

In special cases and for certain types of data, it may be necessary to subsequently overwrite and/or
recreate memory areas on the smart card. Situations may also arise in which existing cards are to be
used for additional purposes. The post-personalization concept can, however, not be elaborated until
relevant experience has been gathered within the framework of the Business Partner Network or
individual requirements are specified by the market participants. The card-specific authentication key
is particularly important here with regard to upwards compatibility and offers an inexpensive means of
protecting smart card data if post-personalization is carried out. This process is now supported by all
major vendors irrespective of the card operating system used. Protection is provided in particular for
the identifier, or in other words, the technically unique name of the holder which should be stored in
read-only format outside the certificate in a protected area of the card. The importance of this process
from an economic perspective warrants a closer look at a number of additional technical aspects.




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                                   25



6 PKI ORGANIZATION
6.1    Purpose and Objective

This section is used to describe the tasks of the individual organizational units and distinguish them
from each other in order to create task specifications. These can then be used as requirements catalogs
for the organizational units themselves or for service contracts that are to be concluded.

Service descriptions are provided by the relevant persons responsible for the organizational units.
They specify the services an organizational unit is to provide along with the required level of quality
in order to perform the defined PKI tasks and to ensure smooth operation. This will, in certain cases,
be of interest to all market participants involved in the procedure (for example, guaranteed minimum
times for revocation service). As already mentioned, the market participants should not be forced to
adopt a standard organizational model. Within the framework of the company PKIs, only
organizational units of all partners involved in joint security mechanisms are required without which it
would not be possible to attain this level of security within the overall network of the ebIX PKI.

6.2    Organizational Units From an Overall Perspective

From an operational perspective, the “PKI” system comprises various PKI organizational units14 and
the levels at which they interact. The organizational units are either part of the central company
organization or companies within the group, or the services they provide are outsourced to external
service providers. Due to the different responsibilities involved, the tasks of the organizational units
must be clearly defined and distinguished from each other. From an organizational perspective, the
PKI system extends across the entire company even if isolated technical applications, such as e-mail
and EDI, are initially integrated. The participating organizational units can reside within the company
or within different companies in the group whereby a consistent namespace is maintained15.

Two company services are crucial for the PKI to function correctly:

The Trust Center service and a publication service, which can be based on a corporate directory16.

The Trust Center performs the following:

 Creates keys in its key generation component (KG),
 Creates certificates in its certification component (CA),
 Archives keys in its key archive component (CA),
 Manages smart cards across the entire life cycle of the certificates
The certification authority provides the following service:

The certification authority17 operates a root entity which acts as the source of trustworthiness. The goal
of the certification authority is to cross-certify with other root entities to create a network of
confidence and to associate a level of trustworthiness with the certificates that goes beyond company
borders.

The company-wide PKI comprises the following organizational units:

14
   The organizational units in the PKI must be equipped with personnel, materials and equipment so that they can
carry out their assigned tasks. The heads of the organizational units are responsible for services to be provided.
15
   Outsourcing individual PKI services to external service providers is optional.
16
   The corporate directory is not described in any further detail in this concept. The corporate directory has an
auxiliary function in the PKI. It is run outside the PKI but must provide the directory service for the PKI.
17
   Secondary certification authorities can also be set up in the group companies. This should not be considered,
however, until sufficient experience has been gathered using the central company solution.


ebIX                                                                                             May 16, 2006
Technical PKI interoperability in the European energy sector                                               26



   PKI division
   Certification authority
   Registration authorities

and the service component

   Publication service

The CIO and the PKI Division

The Corporate Information Officer (CIO) or a similar organizational unit assumes overall
responsibility for security in the PKI system.

The PKI division is the unit responsible for planning and controlling. It is authorized to issue
directives to the PKI organizational units with regard to all fundamental and security-relevant aspects
of the PKI within the scope of the functional responsibility of the CIO and on his behalf. The CIO
implements the security concept for the PKI, plans and controls the development and sequence of
activities involved in the individual services, where appropriate concludes service agreements with
internal or external service providers and establishes external relationships.

It must be possible to justify other organizational forms implemented by the market participants which
should attain the same organizational level of security.



           Operational CA & Reg. Authority                                                   Corporate
                                                                                             directory
                                                                                             Certificate
                                                                                             directory
                                                                                             CLR
          Registration authority           Application for
                                                             Firewall
                                           certification                   Certification authority
           remote                          Certificate
           (many)
                                                                  Smart card
                                                                    manage-                    e
                                                                                            Tim stamp
                                                                         ment               service


                                                             Key           Certificate
                       Holder                                generation    generation            Key archive

                                                                                Cert.
                Documentary
                evidence verifying
                identity                                                        Operational CA




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                           27



6.3     Certification Authority

The certification authority is an organizational unit within the PKI. It performs the following
functions:

     Root entity
     Operational CA
     Smart card management (particularly certificate related)
     Time stamp service (optional)

The certification authority is supervised by the CIO. It is the highest confidence-building authority in
the PKI in the functional certification and key management processes.
The head of the authority is responsible for the availability of the operational CA and for the
trustworthiness of the certificates issued.

Only trustworthy personnel with the appropriate expertise and training are deployed in the certification
authority.

6.3.1     Operational CA

The operational CA is accommodated in a specially protected infrastructure. It comprises the service
components:

     Certification Authority (CA)
     Key Generator (KG)
     Key Archive (KA)

6.3.1.1    Certification Authority (CA)
General overview of tasks

The technical/organizational/physical environment in which certificates are issued is referred to an
operational CA (also known as a Trust Center service). The technical unit responsible from a
cryptological perspective for certifying public keys in accordance with the rules and regulations is
called a CA.

Certificates are issued by the operational CA only. It uses its CA for this purpose. The CA is automatic
and unattended.

The CA signs the certificates with the private key of the operational CA and creates the associated
PSEs. The certification authority also creates the component key material and provides the component
certificates.

Details of tasks performed

The private keys used by the certification authority enjoy special protection and may only be used for
certification purposes.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                                      28


Key and certificate changes are necessary if there is reasonable suspicion that a certification authority
key has been compromised. In this case, the certificate18 in question must be revoked immediately.
The head of the certification authority decides whether operational CA certificates are revoked. The
relevant publication obligations within the EBIX PKI must be implemented. If a large number of
participants who run their own CAs is involved, Authority Revocation Lists (ARLs) must be provided.
The protocol and structure are now standardized. (When a CA key is compromised, however, this is
equivalent to an IT disaster of considerable consequence because all the keys issued by this CA are
invalid. The fall-back scenario is usually paper based. This IT disaster should be taken into account in
the company disaster manual).

The certification authority regularly monitors the validity of all the holder (user) certificates it issues19.
It creates a new key in good time before the normal validity period of a holder (user) certificate
expires, informs the holders concerned that the validity period is about to expire, and requests them to
contact a registration authority in good time so that new keys and certificates can be applied for. The
validity periods of certificates can overlap for a limited amount of time.

Validity monitoring mechanisms that are specifically process related must be specified for component
certificates.

Holder (user) certificates can, in principle, also be issued for business partners.

This should be initiated by a manager with the appropriate authorization.

An attribute in the certificate must indicate whether the holder is a member of staff or an external
holder.

Business partner certificates are basically the same as holder (user) certificates. The rules and
processes of the PKI apply. Other than publication of the certificates, no further disclosure duty is
defined.

Keys that have been generated by business partners themselves can be certified if they fulfill the
security requirements of the PKI Policy20. The decision regarding this is made by the CIO.


List of tasks performed by the CA

(1) Processes the requirements for key material
 Initiates key material generation in the key generation component
 Processes the certificate requirements
 Assigns the key material to the holder data (certificate creation)
 Creates the PSE
 Creates the PIN / super PIN
 Issues the PSE to the registration authority (RA)
 Creates the PIN letter and sends it to the certificate holder
 Enters the certificates in the corporate directory
 Initiates key archiving (KA)
(2) Processes the requirements for certificate revocation
18
   Whether or not all certificates issued previously become invalid depends on which validity model has been
standardized on an international level. See Section 3.3.1 Validity Model
19
   An appropriate requirement and suitable procedure for monitoring the certificates must be specified.
20
   Whether or not key material generated by business partners has to be archived has yet to be specified. If it
does have to be archived, an appropriate agreement must be reached with the business partners in question.


ebIX                                                                                             May 16, 2006
Technical PKI interoperability in the European energy sector                                                     29


    Receives the revocation application and applicant identity and records these in line auditing
     requirements
    Creates the updated certificate revocation list
    Transfers the certificate revocation list to the corporate directory
    Initiates archiving of the certificate revocation list (KA)


6.3.1.2   Key Generation (KG)

Tasks

All key material to be generated centrally21 is generated in the KG component. When key pairs are
created, particular importance is attached to the cryptographic quality of the keys, especially with
regard to the random number generator, which should generate real and not pseudo random numbers22.
Duplicates of public keys are recognized as such and are discarded together with their private keys23.
Generating signature key material

The operational CA initiates generation of the keys for electronic signatures on the smart cards.

6.3.1.3   Key Archive (KA)24

Tasks of KA

The key archive (KA) stores keys and certificates on permanent long-term media. It is also used for
key recovery.

In the PKI, all encryption keys are archived to ensure that company data stored in encrypted form can
be accessed if this is required by the relevant authorities, if an internal audit is performed or in other
cases.

If applicable, legally prescribed minimum archiving periods must be observed.

Details of KA tasks

In the key archive, access to the stored keys and certificates can be provided at several levels:

More recent key material and certificates can be accessed more quickly; older key material and
certificates can, in certain cases, only be accessed once the appropriate organizational preparations
have been made.

The key archive can also be used to restore key material in cases where a holder has inadvertently (the
key has not been compromised) destroyed his keys (for example, a smart card is rendered useless as a
result of external mechanical influence). In general, encrypted data belongs to the company and not
the employee. A key archive for the encryption keys or card-specific keys is, therefore, recommended.
A signature must always be provided by the signature key holder irrespective of whether or not he is
authorized to do so. Care must be taken when signature keys for advanced signatures are restored. This
is not allowed for qualified signatures.

21
   This includes key material for network users.
22
   The conditions and recommendations in the German Federal Gazette no. 213, page 18.638 (or the relevant
valid official publication) must be taken into account.
23
   Preventing duplicates of public keys is necessary because a duplicated public key means that the associated
private key is also duplicated. This function can only be provided within the sphere of confidence.
24
   In countries where key archiving is not legally permitted, local legislation must be observed.


ebIX                                                                                            May 16, 2006
Technical PKI interoperability in the European energy sector                                                    30



A high level of operational security and maximum long-term protection are important factors to be
taken into account for the purpose of setting up and operating a key archive.

The rules and restrictions for operating the key archive and for accessing and managing the archive
should be specified in a special archiving concept by the market participant in question25.

Tasks of KA

    Archive the holder (user) certificates and key material with appropriate reference to the holder
    Archive the component certificates and key material with appropriate reference to the user
     components
    Restore key material under conditions that must be defined in detail
    Ensure long-term archiving and availability
    Monitor expiry of the validity period of the certificates issued and initiate recertification in good
     time

6.3.2    Smart Card Management Service (Optional)

This section only discusses high and medium security levels in conjunction with smart cards. Similar
requirements apply for low and, where appropriate, medium security levels with soft tokens (soft
PSEs).

The smart card management service comprises the personalization system and smart card
administration system. The smart card management service personalizes and manages operation of the
smart cards. The smart card administration system manages the entire life cycle of a smart card. The
personalization system supports either the

    single-stage initialization and personalization process or a
    multi-stage process.

In the case of the single-stage process, the smart cards are initialized and personalized centrally. In the
case of the multi-stage process, the various actions can be divided up among and configured by the
certification and registration authorities.

The single-stage process can be necessary during the implementation phase if large quantities of smart
cards need to personalized and issued to the holders at short notice. The multi-stage process is used
during ongoing operations if individual smart cards have to be personalized for new employees even if
the key material that complies with the Digital Signature Act is to be generated on the holder (user)
smart cards.

The personalization system works together with the smart card administration system.

Secure messaging is used for communicating with the certification authority, that is, sensitive
certification data and, where appropriate, key material is provided with full cryptographic protection
from the source equipment right through to the target equipment.

The smart card administration system uses standard database mechanisms and can, as a result, manage
the smart cards issued and their associated holder data in any combination.

In remote mode, the registration authorities use the PKCS#10 protocol for certification applications.

25
  Specifications will be drawn up at a later point in time and separately from the specifications for the PKI
Policy.


ebIX                                                                                              May 16, 2006
Technical PKI interoperability in the European energy sector                                                        31



6.3.3    Time Stamp Service

A time stamp service is optional because certification service providers are now active on the market
where they have to offer this service publicly to each participant.

Participants are, however, recommended to set up their own time stamp service because each legally
relevant signing process (this includes all the certificates created) must be safeguarded by a time stamp
so that in the event of the CA certification key being compromised, all the certificates issued prior to
the CA certificate being revoked remain valid.

There is currently only one product on the market26 that is certified to the Digital Signature Act/Digital
Signature Ordinance and can be deployed. If a time stamp service is integrated:

     The maximum permitted downtime can be regulated within appropriate service level agreements;
      as a general rule, this should be less than three hours
     The normal response time27 should, where possible, not exceed one minute.
     The response time for creating a time stamp28 must not exceed ten minutes.

Separate signature keys are used for the time stamp service in order to provide sufficient security
should a CA certification key be compromised.

The time stamp service is available to all applications throughout the user group.

6.4     Registration Authority

The registration authorities are entities within the PKI system and are run by the respective group
companies or the accredited certification service provider. The registration authorities (RAs) are
supervised by the certification authority and the CIO.

Registration authorities represent the interface to the certification authority. They are set up locally
near the certificate holders and future holders.

The registration authorities check and document in a trustworthy manner that conforms with auditing
requirements the identities of the persons who apply for and are issued with key material and holder
(user) certificates.

Unique identification of the holder is an important cornerstone of trustworthiness throughout the entire
PKI. The head of the registration authority is responsible for reliably establishing the identity of the
applicants.

Only trustworthy personnel with the appropriate expertise and training are deployed in the registration
authorities29.

Tasks of RA

The registration authorities receive the applications for holder (user) certificates and supply the
applicants with the PSEs on the smart cards30.


26
   TSS developed by Timeproof, Hamburg. No other product is known (as at 2002-04-29).
27
   The time within which the time stamp is sent back to the participant.
28
   The time within which the time stamp is created.
29
   This task can also be carried out by the department in plant security responsible for employee identification.
30
   PSEs should only be issued on diskettes (soft PSEs) in exceptional cases.


ebIX                                                                                              May 16, 2006
Technical PKI interoperability in the European energy sector                                                      32


The registration authorities manage the pre-personalized smart cards submitted to them and keep them
in a safe place.

The registration authorities keep a record of the pre-personalized smart cards and the personalized
smart cards issued in a special smart card administration system.

The registration authority forwards the certification requests with the holder data to the certification
authority31. The communication channel to the operational CA is set up as a secure connection due to
special protection required for the holder data.

PSEs being sent from the operational CA to a registration authority are protected in such a way that
employees of the registration authority cannot access the content of the PSE, thus ensuring that the
confidentiality of the key material is maintained. (end-to-end security between the CA and smart card).

The registration authorities can also issue replacement smart cards that are limited in terms of
functionality and for a specific period of time to persons who have forgotten their personal smart cards
or do not have them at hand32.

The registration authority is supported by a special PKI service component, namely the smart card
issue component.

In the following graphic, the medium level registration process refers to advanced certificates being
issued at a high security level within a company PKI. This process differs from the registration process
that complies with the Digital Signature Act (high level) in that the latter requires a personal
document. Even with a low level process (for example, soft token), identity validation and a separate
channel for supplying the PIN/PUK must be ensured.




31
   In the case of signature keys being generated locally on smart cards, the process for generating the keys on the
smart cards is initiated by the registration authorities followed by the certification process which is initiated by
the operational CA. The smart card which is in the care of the holder is “post-personalized” with the signature
certificate.
32
   Registration authorities can also issue visitor cards.


ebIX                                                                                               May 16, 2006
Technical PKI interoperability in the European energy sector                                                         33




It is recommended that the registration process (one of the most vulnerable parts of the process in a
PKI from an organizational perspective) is based on the requirements mapped. Including a supervisor
in the process for issuing certificates is an optional dual control measure.

The Smart Card Issue Component

The smart card issue component is the tool used by the registration authority. This workplace
environment is set up with the necessary protection. The applicant and holder do not have direct
access to the smart card issue component33.

The smart card issue component comprises the following (at least):

A workstation computer on which the local registration authority software and the smart card
personalization and administration software is installed
A component for communicating securely with the operational CA
A smart card reader for the administrator smart card
A card printer (optional)34 that can write optical and electronic data to the holder (user) smart card to
be personalized




33
   It is yet to be clarified how the smart card issue component can interact with the issue component for plant
security IDs (in future, multifunctional employee identity cards).
34
   If a card printer is not available, just electronic data can be written to the smart cards using the smart card
reader.


ebIX                                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                           34




                 Smart Card Issue Component


                                                 • Workstation computer
                                                 •LRA software
                                                 •Two smart card readers
                                                 •Optional: card printer
                                                 •Pre-personalized smart cards




ebIX                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                                  35



7 CORPORATE DIRECTORY
The corporate directory is a component outside the PKI. It must store and publish at least part of the
certificate directory and revocation list and supply them to the applications. Publish in this case means
making the necessary subset of information accessible to potentially relevant external communication
partners (for example, all market participants) required proactively for encryption and reactively for
signature verification. IP addresses or domain names can be used to restrict the circle of users to a
closed user group. Provision of this service must be agreed upon with the department responsible for
the corporate directory. Creating a corporate directory in conjunction with a PKI is recommended but
not essential. It is sufficient if a repository is set up in front of the company firewall that can be
accessed with the LDAP protocol. The appropriate ports must be opened and safeguarded for this
purpose. One alternative would be to set up http access to the repository data, which is usually
converted internally to LDAP access.

The certificates and revocation list must be made available to the applications so that the relevant
inspections can be performed. This service must be set up on a 24-hour basis and be accessible to all
users involved in the PKI. The certificates are stored and managed in X.509 format (version 3).




            Repository Information is made Available from the
              Directory by means of Shadowing or Chaining
   Variant 1: Shadowing Þ All data copied locally          Variant 2: Chaining Þ Distributed data storage
         DIR server 1                 DIR server 2                DIR server 1                   DIR server 2


                         Data copy                                                   Link




                             Net-                                                   Net-
                             work                                                   work
                                                              Admin.                                 Admin.

                                                              Users
    Admin.           Users               Users              • Local administration                   Users
                                                            • Distributed directory (log. 1 directory from
       • Central administration                               perspective of end user)
       • Periodic shadowing (automat. copy)                 • Deployed in local organizational units;
       • Deployed in central organizational units             predominantly local data is accessed


     Original data                       Data copy or data link




Only the operational CA is permitted to enter and, where appropriate, change or delete certificates and
revocation lists in the corporate directory.

The standardized LDAP protocol is used for access purposes. Access via the Online Certificate Status
Protocol (OCSP) can be set up if required.




ebIX                                                                                           May 16, 2006
Technical PKI interoperability in the European energy sector                                          36


The PKI uses the person-specific entries as a reference when the certificates are created. The directory
service must, therefore, ensure that the data is consistent. The term repository is often used for the
PKI-relevant data subset.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                             37



Appendix A REQUIREMENTS IN TABLE FORM

A.1 General Requirements

1.     Particularly in the case of electronic signatures, the PKI follows the line of the requirements
       specified in European Digital Signature legislation; that is, the signature key is at the disposal of
       the key holder only and a signature can, therefore, be uniquely assigned to a natural person. In
       the case of advanced certificates, this refers to organizational measures for protection and
       processing signature keys and certificates irrespective of the security token. Mass signatures
       continue to be possible.
2.     Organizational, IT and constructional measures shall ensure that misuse of the processes and
       unauthorized access to sensitive information is, for the most part, ruled out. Authorizations shall
       be restricted to a minimum. The principle of dual control shall apply for particularly sensitive
       functions.
3.     An upper limit for response times and a minimum availability of the PKI services shall be
       defined with respect to the external market participants. Internally, any differences shall be
       justifiable and definable.
4.     Secure encryption methods shall be used as of the outset. RSA keys must be at least 1024 bits
       long, symmetric keys at least 112 bits, and keys based on elliptical curves, for example for
       SELMA, at least 160 bits. In Germany, for example, the specifications of the BSI in the German
       Federal Gazette apply.
5.     The usual standards shall be observed for the purpose of creating, distributing and using
       keys/certificates. The technical details of these are described in a follow-up document
       (Certification Practice Statement).

A.2 PKI Component Organization

1.     Exactly one central unit (with backup) that assumes the role of the Trust Center should be set up
       for a market participant with its own CA. The Trust Center functions include generating all the
       necessary asymmetric keys, initializing (pre-personalization) the smart cards (if used) and, if
       requested by an RA, certifying the public keys.
2.     RAs can be set up at the company sites. The tasks of the RAs include requesting certificates
       from the CA as part of the smart card personalization process, identifying smart card recipients
       and reliably issuing smart cards.
3.     Communication between the RAs and CA must be secure to prevent abuse. All activities carried
       out in the CA and RAs relevant to security must be logged in such a way that the time at which
       they were carried out and the person that carried them out (documented by means of a signature)
       are clearly indicated.
4.     Certificates are transferred automatically to an LDAP directory (see Creating/Storing
       Keys/Certificates for further requirements). An OCSP service is provided where appropriate in
       order to check the validity of certificates. Detailed provisions are specified in the CPS.
5.     In the event of a disaster in the PKI central unit, backup PKI services must be available. The
       availability requirements should be fulfilled in these cases too.

A.3 Creating/Storing Keys/Certificates

1.     The PKI is used to create keys and certificates for persons (employees) and processes within the
       company. Keys and certificates can also be created for the employees and processes of business
       partners providing a business relationship exists with the company. The company does not
       establish itself as a public Trust Center on the market as this would afford it a special status
       among the market participants.




ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                            38


2.     Keys for smart cards are generated on the cards themselves unless other technical requirements
       have to be taken into account (for example, with regard to key storage; see below). Signature
       keys should always be generated on the cards.
3.     Keys and certificates generated for persons are usually stored on smart cards
       which are then handed over to the user. No particular form is preferred for handing over keys
       and certificates created for processes.
4.     Keys and certificates that can be used for digital signatures must not be used for other purposes.
       Secret signature keys should only be stored on secure data carriers (smart cards or secure
       hardware modules) and should not be reproducible. This also applies to the keys for Trust
       Center functions.
5.     In the case of smart cards containing signature keys and certificates, the cards and PIN letters
       must be created and distributed in such a way that parties other than the CA and end user (and
       assuming that malpractice on their part is ruled out), not even an RA, is able to use the smart
       card of another user.
6.     PIN letters for smart cards with signature keys are created by the CA and are sent directly to the
       user. They are enveloped in such a way that the contents can, under no circumstances, be
       inferred from the outside.
7      If a user requires a smart card at short notice, it must be possible for a card to be personalized
       and the PIN generated by an RA. These “emergency” cards contain authentication key material
       only and must not contain a signature key.
8.     The validity of certificates for employees and processes is limited to three years. The certificates
       can, if necessary, be revoked before the validity period expires.
9.     The validity of certificates for the CA functions is limited to five years. The certificates can, if
       necessary, be revoked before the validity period expires.
10.    If an employee leaves the company, all the certificates created for the employee to be able to
       carry out his work are revoked immediately. This also applies if an employee of a business
       partner leaves the company.
11.    A certificate that has been revoked cannot be reinstated. Advanced certificates can be suspended
       for a set time under specially defined conditions.
12.    Certificates for employees of the company should not become invalid solely as a result of the
       employees‟ function, position within the organizational structure or location changing. The
       name of a certificate holder should only be supplemented by a non-informative designation to
       render the name unique.
13.    In the case of secret keys that are used for storing data/documents in encrypted form,
       mechanisms for storing them securely and restoring them can be provided. If secret keys are
       stored, they cannot be generated on the smart cards. The procedure and authorizations for
       restoring keys must be specified by the market participant or on his behalf.
14.    The certificates are published in an LDAP directory. Detailed provisions are specified in the
       CPS. Signature certificates can only be published (internally or externally) subject to national
       legislation and, even then, only with the approval of the certificate holder (e. g. German Digital
       Signature Act).
15.    Due to the fact that the certificates are published, they must not contain any data, which if
       published, violates the regulations of the Federal Data Protection Act. The certificates must, in
       particular, not contain information assigned by the employer, for example personnel numbers or
       organizational details.

A.4 Processing Keys in Client Software

To ensure that the key storage mechanisms are independent of the encryption programs, the
cryptographic functions shall be accessed by the client software via the PKCS#11 or Microsoft CSP
interface. Encryption program here refers to the signature function.

A.5 Cost Allocation




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                         39


Certificates and/or smart cards can be allocated (at least within the company) in accordance with an
appropriate allocation method. No “external” costs are incurred for the market participants. Each party
establishes its own infrastructure in line with the requirements for security and interoperability and
bears the costs for this. Specific agreements may however be necessary for access to CRLs and/or
OCSP.




ebIX                                                                                   May 16, 2006
Technical PKI interoperability in the European energy sector                                               40



Appendix B SUMMARY OF REQUIREMENTS FOR PERSONALIZATION

The following should also be possible in addition to smart cards being created and personalized
centrally by means of batch processing:

B.1 Central Card Initialization (Pre-Personalization)

1.     Cards are initialized by the CA.
2.     Each card is assigned a unique card number, which is also printed on the
        card. If data for a card is to be stored at the CA, it shall be possible to locate it
        using the card number.
3.     The key pairs for signing and identification purposes are generated on the
        card itself.
4.     The key pair for data encryption is generated by the CA software or separate
        hardware and is transferred to the card. The secret key is archived safely with
        the card number.
5.     Additional data (for example, for SSO) is generated at the CA, loaded to the
        card and stored in a secure location. The data must be stored on the
        mainframe or in such a way that the mainframe can access it by means of a
        secure channel.
6.     A transport PIN is created and stored in a secure location.

B.2 Sending the Initialized Cards to the LRAs (Where Appropriate with the Transport
    PINs)

To be specified

B.3 Card Personalization at an LRA

1.     The LRA informs the CA of the person the card is assigned to.
2.     The LRA requests the certificates for the user for the public keys on the card.

B.4 Automatic Activities at the CA due to Card Personalization (Without Intervention
    of a CA Operator)

1.     A certification request made by an LRA is processed. The certificates are stored in a directory
       and transferred to the card by means of a secure channel. The data transferred to the card should
       be encrypted by the CA and then not decrypted until it is on the card.
2.     When a card is assigned to a user, a user PIN is generated and transferred to the card by means
       of a secure channel. A PIN letter is also sent to the user. The Digital Signature Act specifies that
       a PIN must contain 6 digits. PUKs should also be permissible.
3.     The data stored under the card number is assigned to the person in question. An external process
       is initiated with which further activities can be carried out for the user.

B.5 Card Application Procedure

1.     Alternative 1: The user completes an application form and takes it to the LRA.
       a)    The user identifies himself to the LRA.
       b)    He confirms that the information on the application form is correct.
       c)    The LRA operator personalizes a card on the basis of the information provided and issues
             it to the user. The user provides his signature confirming that he has received the card.
       d)    As a result of the personalization process, the CA sends a PIN letter to the user. The user
             can then use the card once he has received the PIN.


ebIX                                                                                            May 16, 2006
Technical PKI interoperability in the European energy sector                                      41


2.    Alternative 2: The user sends the application data to the LRA in advance.
      a)    The user completes a written or electronic application form and sends it to the LRA.
      b)    The LRA operator personalizes a card on the basis of the information provided.
      c)    As a result of the personalization process, the CA sends a PIN letter to the user.
      d)    The user goes to the LRA (at which point he may have already received the PIN letter)
            and identifies himself.
      e)    He confirms in writing that the data provided is correct.
      f)    The LRA hands over the card to the user. The user provides his signature confirming that
            he has received the card.
The user can then use the card once he has received the PIN.




ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                               42



Appendix C SUMMARY OF REQUIREMENTS FOR DIRECTORY/REPOSITORY

C.1 Requirements Regarding Validation

1.     It must be possible to find the certificate of a user on the basis of the user's name and
       organizational details (name, physical name or Distinguished Name (DN), group company,
       location, telephone number, e-mail address, and so on).
2.     It must be possible to determine the user of a signature certificate.
3.     A certificate shall not contain any organizational details to ensure that the certificate remains
       valid if the employee is relocated within the company. The physical components of a name
       should remain unique for at least 100 years.

C.2 Solution Proposal

1.     The unique path of the user is entered in a directory tree. The path comprises the organizational
       and/or local assignment of the user. The user can be found on the basis of this information when
       a search is carried out.
2.     The user data contains the certificates assigned to that user. A user can have several certificates
       for different purposes or several certificates for the same purpose, of which only one is (still)
       valid.
3.     The DN of the certificates comprises the last and first name of the user and a unique non-
       informative number as a global ID which is valid for at least 100 years. Further provisions are
       specified in the recommendations for the certificate content.
4.     If the user‟s organizational assignment or name changes, the same unique number is retained. It
       identifies the user permanently and uniquely.
5.     The process by which the number is assigned to the user still has to be elaborated. Companies
       are distinguished from each other by means of an appropriate unique code number, e. g. GLN.
       Lifetime e-mail addresses are being used to an ever increasing extent by companies.
6.     The user data in the directory tree also contains the unique number enabling a link to be
       established between the certificates and user.

C.3 Other Aspects

1.     If the personalization data does not contain a unique number when a certificate is created, a
       search is made for it in the user entry in the directory tree. A decision must be made in advance
       as to how a new number is to be assigned if a number has not been entered here either.
2.     The recommendation regarding "vertical interoperability" in the declaration implies that
       advanced and qualified signatures are upwards compatible (incl. provider accreditation in
       accordance with section 17 of the Digital Signature Act). From a technical perspective, this
       means that validation is carried out in accordance with the chain model as prescribed in the
       Digital Signature Act. Suitable organizational provisions should be made to counteract
       undesirable consequences (for example, as a result of company take-overs). The restrictions to
       be observed in accordance with the Digital Signature Act for certificates being read by other
       (unspecified) users must also be clarified. Provisions that conform with the Data Protection Act
       must also be agreed upon for circulating certificates that are restricted with regard to publication
       (if the market participants are further segmented) outside the target group.
3.     It must be possible for the procedure to function with several CA keys (because, for example,
       CA keys are valid for a limited period of time and new keys have to be created on a regular
       basis). Only the CA is permitted to enter and change certificates and the unique user numbers.
4.     The subset of employee data required for publication can be placed in a repository from an
       X.500 entry that exists in practically all standard corporate directories by means of shadowing
       mechanisms. Cross-certification would then use chaining mechanisms to mirror the contents for
       the cross-certified partner in the partner‟s repository.


ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector              43




ebIX                                                           May 16, 2006
Technical PKI interoperability in the European energy sector                                                44



Appendix D NOTE ON POST-PERSONALIZATION

The following procedure is recommended for subsequent personalization steps which do not involve a
change of key material:

The identifier is written to the secure area of the card.

The identifier is the technically unique name of the card holder and is included in the certificate. The
link established by the identifier between the card and card holder is as unique as the link that must be
established between the key to be certified and the card holder. The identifier must be stored
temporarily in a secure location because it must be possible for the certificate to change without the
signature key pair changing (UPDATE NEV).

Recertification and other post-personalization activities are carried out at a separate location and at a
separate time.

They should, however, include the following steps:

The public key of the signature application (PK.CH.DS) is read from the card (and not from a directory
where it is stored).

PK.CH.DS is overwritten by the card-specific authentication key SK.ICC.AUT.

The identifier is read from the card (and not from a directory where it is stored).

The identifier is also overwritten by the card-specific authentication key SK.ICC.AUT and is,
therefore, cryptographically secure.

Both are transferred to the Trust Center by means of a secure channel.

The Trust Center provides a signature to confirm the link between the identifier and public key.

This can be carried out in a technically non-secure environment (without secure messaging) when the
data identifier and public key on the card have been signed using the certificate specific to the card
itself. This can take place individually or by means of a PKCS#10 request that is signed by the
authentication key.

Technical verification of the:

   card origin of the public signature key
   the relationship between the identifier and public key

can be performed in the Trust Center.

The card signature is an efficient means of ensuring that this is carried out securely.

Organizational verification of the card holder (technical name) together with the identity is carried out
at the registration authority by means of a personal document and is confirmed by the digital signature
of the registration officer.

In this process, the technical name plays a key role because it is a joint means of identification for both
data versions (before and after post-personalization).




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                           45


The signature interoperability specifications, however, require the use of Distinguished Names that
can be deployed in a public legal framework (see SigI, Appendix I (Certificates), page 24 ff).

Using proprietary identifiers alone is, therefore, not recommended when considered from a migratory
perspective.

Because the identifier links both certificate policies and because the card itself is used to
cryptographically safeguard the link between the card origin and public key of the signature,
expensive business terminals should, therefore, not be necessary in the registration process.

Activities such as resetting the maloperation counter could then be carried out on a small number of
administration terminals with security modules and secure messaging.

This procedure ensures that future applications can be supported in a cost effective and reliable
manner without now having to plan all of these applications explicitly in the form of predefined card
structures.

The only requirement here that applies to all manufacturers is that the identifier and the authentication
key associated with the unique card identity are stored separately.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                       46



Appendix E GLOSSARY

Archiving (digitally signed   Archiving is defined by law in different ways. Examples from
documents)                    Germany:
                              The generally accepted principles of computerized accounting
                              (GoBS) of November 7, 1995 - IV A 8 - S 0316 - 52/95- Federal
                              Tax Gazette 1995 I page 738 specify the procedural documentation
                              and also apply for qualified electronic signatures and separation of
                              form and content. See also the principles for data access and
                              verifiability of digital documents (GDPdU) in which requirements
                              for the purpose of tax audits are explicitly defined.
                              See also section 257 of the German Commercial Code with regard
                              to WORM archiving.
                              Further (technical) consequences are currently being defined.
Asymmetric cryptography       A mathematical data encryption procedure in which two different
                              mathematically related keys are used to encrypt and decrypt data.
Authentication                Normally used in 2 different contexts:
                              User authentication
                              Users authenticate themselves vis-à-vis an application. The
                              signature key should not be used for this purpose because this
                              should (or must in accordance with the Digital Signature Act) be
                              reserved for the signing process.
                              Component authentication
                              Card-specific authentication key safeguards communication
                              between the card and the outside world, for example via secure
                              messaging.
Bridge CA                     Deutsche Bank and Deutsche Telekom founded the Bridge CA in
                              October 2000. The operator is TeleTrusT Germany. The Bridge CA
                              is neutral, international, spans all industries and is not profit
                              oriented. It enables all its members to exchange e-mails securely
                              with each other. The rules that govern its activities were defined
                              within the framework of a public/private partnership. In order to win
                              public confidence in the Bridge CA, an independent advisory board
                              comprising experts from trade and industry, management and the
                              scientific world is being set up to carry out supervisory duties.
                              Bridge CA is under the patronage of the German Minister of the
                              Interior and serves as a basis for secure e-government as part of the
                              “BundOnline2005” initiative of the Federal Government.
                              www.bridge-ca.org
BSI                           The work carried out by Federal Office for Information Security
                              (BSI) on behalf of the German regulatory authority for
                              telecommunication and postal services (RegTP) involves defining
                              requirements for qualified electronic signatures.
                              Most important documents:
                              Catalog of measures for digital signatures, November 18, 1997.
                              Signature interoperability specifications (e.g. Section 1 Certificates;
                              Section 2 Signature; Section 3 User Infrastructure; Section 4, Time
                              Stamp, and so on).
                              All documents are available at www.bsi.bund.de, many in English.
Business terminal             Signature creation device in a public (that is, not private or
                              company) environment which must authenticate itself vis-à-vis a
                              smart card which, in turn, must authenticate itself vis-à-vis a
                              terminal before a signing process can be carried out. This procedure


ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                       47


                              is called component authentication, and the communication that
                              takes place secure messaging. The business terminal is equipped
                              with a security module and a 2-row display for a user-specific
                              display message for checking the process. The process is described
                              in DIN 17.4 and has been included in the signature application by
                              the ZKA; see:
                              sg_ve07 Signaturanwendung V07, status: 180301.doc
CA                            Certification Authority: entity that establishes a link between a
                              public key and a user in the form of a certificate and certifies this
                              with its own digital signature.
                              According to the German Digital Signature Act, the following
                              certification authorities (including spin-offs) have been accredited
                              (since the start of 2002):
                              TeleSec Product Center of Deutsche Telekom AG, Netphen
                              Deutsche Post eBusiness GmbH (formerly Signtrust), Bonn
                              DATEV eG, Nuremberg
                              Chamber of German Tax Advisors, Nuremberg
                              Medizon AG, Berlin
                              Chamber of German Tax Advisors, Saarland, Saarbrücken
                              Hanseatic Chamber of Tax Advisors, Bremen
                              Federal Association of Notaries, Cologne
                              TCTrustcenter, Hamburg
Certificate                   A certificate is an electronic identifier containing a signature that
                              was created by a certification authority with a private key. The
                              authenticity of the key is checked by the recipient. The term
                              “certificate” is defined as follows in the Digital Signature Act:
                              Within the meaning of the Digital Signature Act, a certificate is a
                              digital attestation with a digital signature confirming that a public
                              signature key is assigned to a natural person (signature key
                              certificate) or a special digital attestation that contains further
                              information with unique reference to a signature key certificate
                              (attribute certificate).
                              The structure of certificates that comply with the Digital Signature
                              Act is described in the BSI signature interoperability specifications,
                              section A1, Certificates.
Certificate user, relying     These are persons, organizations, processes or devices that use the
party, recipient, verifier    certificate or the public key it contains for encryption (before the
                              data is sent) or verification (after the signed data has been received)
                              purposes.
Chip card                     Credit-card format card with an embedded microchip accessed
                              externally as defined in ISO 7816. If this microchip is equipped with
                              a programmable controller (CPU), the card is called a smart card.
Corporate directory           The corporate directory is a list containing employee-related
                              information that is available throughout the company. It is also used
                              to publish certificates and make these available throughout the
                              company or to make part of the information (for example, last name,
                              first name, e-mail address and certificate) available externally by
                              means of suitable mirroring mechanisms.
CRL                           Certificate Revocation List, negative list of revoked certificates,
                              positive list = Certificate Positive List CPL
                              Provisions specified in X.509.
                              www.ietf.org/rfc/rfc2459.txt replaced by RFC 3280
Crypto algorithm              Set of mathematical rules for carrying out cryptographic operations
                              (such as encryption and hashing) recursively on the basis of



ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                     48


                              elementary mathematical functions (such as shift, multiplication,
                              calculate remainder) using keys and parameters.
CSP                           Cryptographic Service Provider
                              A software module that performs cryptographic operations. The
                              CSP interface is the standard Windows interface to chip cards
                              equipped with cryptographic co-processors. It competes with the
                              PKCS#11 standard. Converters are available (from Secude).
DES                           The Data Encryption Standard (DES) is a cryptographic algorithm
                              (that is, a self-contained encryption calculation process with a
                              legitimacy that is repeated cyclically) developed by the American
                              National Bureau of Standards (NBS) for encrypting and decrypting
                              data. The DES algorithm was developed by IBM in the 1970s for
                              the National Bureau of Standards and uses a 64-bit key which
                              allows combinations of data substitutions, transformations and
                              exclusive OR functions. The 64-bit data record comprises an
                              effective key length of 56 bits and 8 parity bits. The Data
                              Encryption Standard, the most well known and tried-and-tested
                              symmetric encryption procedure, was published in 1974 and
                              standardized in the USA as an ANSI standard (ANSI X3.92-1981).
                              It has been used for many years, in particular, to transfer sensitive
                              data such as that encountered on capital markets and can be
                              regarded as an international quasi standard. The DES standard is
                              due to be replaced in 2001 by an improved version, namely the AES
                              standard.
Digital signature             A digital signature cryptographically converts data so that it cannot
                              be tampered with unnoticeably (protecting the integrity of the data).
                              Digital signature is usually associated with the process of digital
                              signing, which can be subject to regional laws and regulations. The
                              meaning here is more general, that is, it does not correspond to a
                              possible Digital Signature Act.
Digital Signature Act         Version of the law published on May 21, 2001 in the Federal Law
                              Gazette governing general conditions and constraints for electronic
                              signatures and for amendments to further regulations, Federal Law
                              Gazette 2001 part I, no. 22, page 876 ff.
                              www.regtp.de/gesetze/start/fs_04.html
Digital Signature             Ordinance for electronic signatures and for converting fees and
Ordinance                     charges to euros, as at: November 30, 2000 – Ordinance of
                              November 16, 2001, Federal Law Gazette I p. 3074 enacted on
                              account of section 24 of the Digital Signature Act.
DIN standard, electr.         DIN NI-17.4, Version 1.0, 15.12.1998, available at BSI,
signature                     www.bsi.bund.de.
Distinguished name            Technical name of a directory entry.
                              In line with the CCITT recommendations X.520, Selected Attribute
                              Types.
EESSI (European               Most important European standardization committee for digital
Electronic Signature          signatures.
Standardization Initiative)   The purpose of the guideline of the European Union is to facilitate
                              use of the electronic signature and its legal recognition in the EU.
                              The aim here is to ensure that the common market can also function
                              in the field of electronic trading. In order for business partners
                              outside the EU to be able to provide legally valid electronic
                              signatures for partners within the EU, their issuing certification
                              authorities must be recognized (accredited) by a certification
                              authority in one of the EU member states. This does not, however,



ebIX                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                                       49


                              mean that interoperability is ensured. This also requires that
                              technical standards that must be defined by suitable workgroups are
                              adhered to. These standards make it possible for software products
                              and services to be offered on a freely competitive basis. The
                              European industrial and standardization committees launched the
                              European Electronic Signature Standardization Initiative (EESSI)
                              for this purpose. On July 1, 1999, a draft was presented that will be
                              developed further in conjunction with the Internet Engineering Task
                              Force (IETF).
                              http://www.ict.etsi.org/eessi/EESSI-homepage.htm
Encryption                    Encryption prevents unauthorized persons or third parties from
                              making use of the electronic data transferred. Mathematical methods
                              are used for this purpose that convert (encrypt) the data to a readable
                              yet unusable form. Conversion back to the original form
                              (decryption) can only be performed by authorized persons,
                              organizations, processes or devices.
                              Encryption prevents unauthorized access to protected information.
                              Different encryption methods are used for the three basic
                              cryptographic methods (Link-by-Link, Node-by-Node and End-to-
                              End): transformation, substitution, code book, DES and public key
                              systems such as RSA. Encryption can take place directly at the
                              higher protocol levels or by means of suitable additional equipment
                              connected between the data terminal equipment and data
                              transmission equipment. As work on international standardization
                              continues to progress rapidly, a standardization office of the ISO
                              was set up at the GMD in Bonn. Since January 1991, this has been
                              the Federal Office for Information Security (BSI) in Bonn with the
                              task of detecting possible causes of risk for computer systems.
Form Adjustment Act           The law for amending the formal requirements in private law and so
                              on specifies the changes in German law that are necessary as a result
                              of the Digital Signature Act and the options it offers with regard to
                              electronic signatures (Federal Law Gazette I 2001 no. 35, 1542,
                              August 1, 2001).
GDPdU                         Principles of data access and verifiability of digital documents
                              (GDPdU), letter of the German Federal Ministry of Finance, dated
                              16 July 2001, - IV D 2 - S 0316 - 136/01 -).
                              This document specifies for the first time requirements for archiving
                              and accessing encrypted or signed documents and the associated key
                              material or certificates for the purpose of tax audits.
Global Identifier (GID)       PKI is always closely associated with X.500 Directory Services.
                              Although technical naming conventions exist with X.520, there is
                              no unique namespace, such as for SMTP mail.
                              A unique identifier is, therefore, required within a PKI, often
                              referred to as a global identifier.
                              It should be stored in the cryptographic token (soft token, smart
                              card, and so on) outside the certificate.
Hash algorithms               When a document is hashed, a 160-bit number, for example, is first
                              created (one-way function). It is extremely unlikely that the same
                              hash value exists for different documents (collision resistant). The
                              hash value is then signed with the private signature key.
                              The document recipient validates the document using the public
                              signature key of the signee once the hash value has been calculated
                              for the document.
                              Secure hash algorithms include: MD2, MD5, SHA-1, RipeMd128,
                              RipeMd160


ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                      50


                              SHA-1 or RipeMd-160 are often used and are recommended by the
                              BSI.
                              For suitable crypto algorithms see: www.bsi.de/fachthem/index.htm
Identrus                      Identrus LLC headquartered in New York was founded in April
                              1999. 40 financial institutions are now members of Identrus. The
                              Identrus system is based on a legal and technical infrastructure,
                              which is regulated by means of legal and technical requirements.
                              The Identrus network is a closed user group which is open to banks
                              and their business customers. The basic aim here is the unique
                              identification of the trading partners in B2B business.
ISIS                          ISIS (Industrial Signature Interoperability Specification) was
                              developed by the working group Trust Center for digital signatures
                              (AGTC) in conjunction with the BSI. It defines standard formats for
                              files and messages that are used for services provided within the
                              meaning of the Digital Signature Act. ISIS currently includes
                              formats for certificates and directory services and will be extended
                              to include other formats such as those for time stamps. The ISIS-
                              MTT standard was adopted together with the Teletrust association.
ISIS-MTT                      ISIS-MTT is a joint specification of TeleTrusT and the T7 group
                              (Trust Center association) for electronic signatures, encryption and
                              Public Key Infrastructures. It comprises a:
                              basic specification containing the following parts:
                              Part 1: Certificate and CRL Profiles,
                              Part 2: PKI Management,
                              Part 3: Message Formats,
                              Part 4: Operational Protocols,
                              Part 5: Certificate Path Validation,
                              Part 6: Cryptographic Algorithms,
                              Part 7: Cryptographic Token Interface
                              and an optional Digital Signature Act profile.
                              A test suite/test bed has been developed for the specification, which
                              provides a basis for ensuring conformity for manufacturer and user
                              interoperability tests.
Key archive                   KA
                              Entity in the Trust Center responsible for key archiving, see also
                              Key Generation (KG).
Key backup                    “Key backup” is an entity in the enterprise PKI organization
                              responsible for backing up private keys with which data, of which
                              the non-encrypted original version is no longer available, is to be
                              decrypted. This component of the PKI accepts, stores and provides
                              access to private keys and enables the requirement for recovering
                              original data to be fulfilled. Only the company in question is
                              responsible for key backup.
Key certificate               A certificate links a public key to information that identifies a
                              person, organization, process or device as the user of the associated
                              private key. In the case of a certificate for a personal key, this
                              information basically comprises the identity data of the key owner.
                              In the case of a certificate for a key that is not linked to a person,
                              this information identifies a department, a function, a server, an IT
                              system, or a process that is authorized to use the associated key.
Key escrow                    Also called lawful access. Access keys for encrypted documents are
                              held by a third, fiduciary entity outside the company. This can be a
                              notarial or government entity. Lawful access is not used or is not
                              permitted in Germany. This function is, however, necessary on



ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                      51


                              account of the cryptographic export guidelines in other countries.
                              (See also the Wassenaar agreement).
Key generation                KG
                              Entity in the Trust Center responsible for generating keys. Signature
                              keys should be generated on the card using the latest available
                              technology. If the key generation process with later chip generations
                              is fast enough to ensure that no considerable delays (in the vicinity
                              of seconds) occur in the personalization process, all asymmetric key
                              pairs should be generated on the card so that the private key never
                              leaves the secure area of the chip.
Key holder                    The holder of a key is the end user who is assigned a private key (in
                              the form of a Personal Security Environment, or PSE) and is
                              responsible for its correct use.
                              In the case of a personal key pair, the owner is also the holder
                              because it is forbidden to make the personal key available to anyone
                              else.
                              In the case of a non-personal key (for example, function key, server
                              key, and so on), the owner and holder can be different persons. Such
                              a key is sent from the owner to the holder and then back from the
                              holder to the owner.
                              Server keys (that is, keys for authenticating servers), process keys
                              (for example, code signing) or keys for IT systems and equipment
                              are generally imported into these where they can then be used
                              independently. The import is carried out by the owner or by the
                              holder on behalf of the owner.
Key material                  Personal key material (Personal Security Environment) and the
                              associated (public) key certificate.
Key recovery                  Key recovery is the process by which key material is made available
                              again. Key recovery for a company can be carried out for a number
                              of different reasons (for example, loss of key material, business data
                              accessed by management, and so on). Access to the archived key
                              material is always governed by special provisions. In the case of
                              signature keys, recovery outside the legal framework of the Digital
                              Signature Act should not be possible.
Key user                      See also Key holder.
                              In the case of stored encryption keys, the key holder is not
                              necessarily the key user; “key holder” here can refer to the legal
                              person (for example, the employer), who provides the natural person
                              (as key user) with the key material. Signature keys cannot be stored.
                              In this case, the natural person is both the key holder and the key
                              user; this person has full control over the private key and must be
                              uniquely identifiable.
Key, key pair                 Two keys comprising a private and a public key required for the
                              purpose of asymmetric cryptography are referred to here as a key
                              pair, or key for short.
LDAP                          Lightweight Directory Access Protocol
                              LDAP is a TCP/IP-based directory access protocol which has
                              become a standard solution on the Internet and in company
                              intranets. It is derived from the X.500 directory access protocol
                              (DAP) and provides simple access to X.500-based and non-X.500-
                              based directory systems. The LDAP protocol does not define
                              directory content nor does it specify how directory services are to be
                              provided. It builds on TCP/IP and uses a client/server model where
                              the server is an X.500 server. LDAP has a globally unique format



ebIX                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                                       52


                               that supports any kind of name; it provides different layouts and a
                               unique relationship between the name and its internal
                               representation. LDAP is specified in RFCs 1777, 1778, 1779 and
                               1781. The protocol was standardized in 1999 by the IETF.
LRA                            Local Registration Authority;
                               Authorized, user-oriented authority which identifies and
                               authenticates users and which manages and hands over the key
                               material to the users.
Maßnahmenkatalog für Dig       The central reference point for legal requirements according to the
Sig (catalog of measures for   German Digital Signature Act and their interpretation as well as
dig. sig.)                     information on organizational and technical implementation.
                               www.bsi.de/fachthem/index.htm
Message authentication         MAC
code                           Information that ensures the integrity of a message. The MAC can
                               also be used in a symmetric key system to verify the authenticity of
                               the sender.
Message recovery               Messages are encrypted “normally” with the public key of the
                               recipient. A copy of the message is also encrypted with the client
                               key of an administrative unit within the company (Corporate
                               Security Officer, CSO); see also Key Escrow.
MeT (Mobile Electronic         The MeT was founded in April 2000 by Ericsson, Motorola and
Transaction Forum)             Nokia. The MeT is now also supported by Panasonic, Siemens and
                               Sony. The forum aims to develop a framework for secure mobile
                               transactions to ensure that e-services, e-commerce and e-
                               government can be used consistently by the consumer irrespective
                               of the terminal equipment, service or network deployed. MeT is
                               based on WAP technology. Like most of the other forums, MeT
                               intends to promote interoperability between the companies involved
                               in the value chain and between different countries.
                               http://www.mobiletransaction.org
MoSign (Mobile Signature)      The 4 major German banks Commerzbank, Deutsche Bank,
                               Dresdner Bank and HypoVereinsbank formed a collaborative
                               partnership for the purpose of implementing a “mobile digital
                               signature”. The aim of the “MoSign” project is to provide business
                               and private customers with a joint, open standard for secure online
                               transactions via cellular phones and organizers. Within the
                               framework of the ”MoSign” initiative, banks work with the
                               international system vendors, and terminal equipment/software
                               vendors Compaq, CoCoNet, emagine, Ericsson, Hewlett Packard,
                               Materna, Microsoft, Sema, Siemens and the TC Trust Center. The
                               development of proprietary solutions has been consciously avoided.
                               Smart cards are currently being used with certificates that are
                               Identrus compliant. http://www.mosign.de
mSign (Mobile Electronic       The mSign consortium was founded at the end of 1999 by Brokat
Signature Consortium)          and today includes 35 members form all areas of the value chain for
                               mobile digital signatures. The members include mobile network
                               operators (T-Mobile, D2 Vodafone, E-Plus, etc.), financial institutes
                               (Advance Bank, HypoVereinsbank, etc.), service providers (NSE,
                               PAGO, etc.), smart card providers (ORGA, Gemplus, etc.), terminal
                               equipment manufacturers (Siemens, etc.) and Trust Centers
                               (TCTrustCenter etc.). As an international association, mSign aims to
                               provide a basis for developing a global de facto standard for an
                               interoperable application infrastructure for mobile digital signatures
                               between the companies involved in the value chain. mSign and



ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                         53


                              Radicchio formed a strategic partnership in February 2001.
OCSP                          OCSP (Online Certificate Status Protocol) is a protocol for online
                              certificate validation.
                              When OCSP is used for certificate status checks, the OCSP client
                              sends an OCSP request to an OCSP responder. This OCSP
                              responder must be authorized to provide information on the current
                              certificate status. The OCSP is transport independent which means
                              that it can be based on any Internet protocol.
                              The request includes the following information:
                                Protocol version
                                List of certificate identifiers
                                Name and signature of the client requesting the status (optional)
                                Optional extensions that may be processed by the OCSP responder.
                              A normal response comprises the following information:
                                Version and type of response
                                Name of the OCSP responder
                                List with status information: Each certificate identifier is assigned
                              the status "good”, “revoked” or “unknown”.
                                Time stamp
                                Optional extensions
                                Signature of the OCSP responder computed across the hash value
                              of the response: In addition to the signature, information
                              (certificates) can be supplied for the purpose of verifying authority.
                              The protocol does not specify how status information is obtained by
                              the OCSP responder. OCSP responder input usually takes the form
                              of a CRL.
                              ASN.1 is used to define the data structures of the protocol.
Operator, of a PKI IT         An operator within the meaning of this policy is the operator of an
system                        IT system, or the party that provides a service or runs an application,
                              who is responsible for introducing and removing key material
                              (function, server, or other non-personal key) and for ensuring that it
                              is used securely. This task can be delegated to an administrator, who
                              as the holder is then responsible for the key material and its use.
Owner, key owner              The owner of a key pair is the end user who is responsible for
                              ensuring that the private key is used correctly and that its integrity is
                              protected. The owner is also responsible for revoking the key pair.
PC/SC interface               The personal computer/smart card interface is a software
                              architecture with application programming interfaces that allow
                              applications to work with smart cards.
PEM                           PEM, Privacy Enhanced Mail, is a standard for transmitting e-mails
                              securely. It was developed by the PSRG and published in 1989 by
                              the IETF with a request for comments (RFC 1421 to 1424). The
                              DES is used for encryption purposes.
                              Key management is based on RSA, DES, or Triple DES. PEM
                              accepts X.509 certificates. Since the standard is only supported by
                              industry (in contrast to S/MIME) in a few cases, there is little
                              prospect for it being used in future.
Personal key                  An asymmetric key pair is a personal key pair when the holder and
                              owner of the associated Personal Security Environment have to be
                              the same person, and the name of that person is certified in the
                              certificate.
Personal key, private key     The private key is the secret part of the key pair (of a personal key
                              or function key) that is used in asymmetric cryptography.
Personal Security             PSE



ebIX                                                                                   May 16, 2006
Technical PKI interoperability in the European energy sector                                        54


Environment                   The key material in its entirety: in particular the private key,
                              certificates and other information used to identify a user.
                              The main components of the Personal Security Environment (PSE)
                              are the private key and other information belonging to the user who
                              has sole access to the private key. For this reason, the PSE must be
                              protected against unauthorized access. Smart cards, chip cards and
                              diskettes are examples of data carriers on which the PSE is stored.
Personalization               Personal data consolidated to form card data.
PGP                           Pretty Good Privacy is a computer program developed by Phil
                              Zimmermann in 1991 at RSA, which encrypts and decrypts data. It
                              is the most widely used cryptographic software on the Internet.
                              Programmers from all over the world have collaborated on
                              subsequent PGP versions and user interfaces. The software has been
                              available since 1994 without a license being required. PGP uses
                              RSA‟s public key encryption system. PGP also uses an encryption
                              system called IDEA, developed in 1990 by Xuejia Lai and James
                              Massey.
PIN                           Personal Identification Number
                              A combination of numbers that authenticates a user and is used to
                              keep the PSE, in particular the private key stored in it, secret.
                              A distinction is made between a transport PIN and a user PIN.
                              6-digit user PINs are prescribed for signatures that conform with the
                              Digital Signature Act.
                              The PINs are stored securely in the dedicated file of the signature
                              application. A counter (often 1) counts the number of signatures
                              after the PIN has been entered.
PIN, Personal Identity        The PIN is a password with which an end user authenticates himself
Number                        when he accesses the Personal Security Environment. The PIN is
                              used to protect the PSE, in particular the private key it contains.
PKCS                          Public Key Cryptography Standards from RSA Labs.
                              PKCS #1: Describes the RSA Encryption Standard. Incorporates
                              and provides recommendations for implementing public key
                              cryptographic systems based on the RSA algorithm.
                              PKCS #2 and PKCS #4 have been integrated in PKCS #1.
                              PKCS #3: Diffie-Hellman key agreement standard. Version 1.4,
                              November 1993. Contains a method for implementing the Diffie-
                              Hellman protocol.
                              PKCS #5: Password-Based Encryption Standard. Version 1.5,
                              November 1993. Provides recommendations for implementing
                              password-based cryptography.
                              PKCS #6: Extended-Certificate Syntax Standard.
                              Describes the syntax for extended certificates comprising a
                              certificate and a set of attributes collectively signed by the holder of
                              the certificate.
                              PKCS# 7 (Cryptographic Message Syntax Standard) describes the
                              general syntax for data that can be processed using cryptographic
                              methods and therefore describes the combination of signed
                              document and digital signature.
                              PKCS #8: Private-Key Information Syntax Standard describes the
                              syntax for symmetric cryptography. It also describes the syntax for
                              private keys for a number of asymmetric algorithms and a set of
                              attributes.
                              PKCS #9: Selected Attribute Types defines selected attribute types
                              for use in extended certificates to PKCS #6, digitally signed
                              messages to PKCS #7, private keys to PKCS #8 and certification


ebIX                                                                                  May 16, 2006
Technical PKI interoperability in the European energy sector                                       55


                              requests to PKCS#10.
                              PKCS #10: Certification Request Syntax Standard describes the
                              syntax for requesting certification of a public key, a name, and
                              possibly a set of attributes.
                              PKCS#11 defines a program interface to cryptographic functions
                              such as chip cards with a cryptographic co-processor and isolates
                              the application from the middleware.
                              PKCS#12 defines the file format of software-based cryptographic
                              tokens (soft tokens). It specifies a portable format for storing or
                              transporting a user‟s private keys, certificates and other secret data.
                              PKCS #13 (Elliptic Curve Cryptography Standard) is still being
                              developed. It will address many aspects of elliptic curve
                              cryptography, including parameter and key generation and
                              validation, digital signatures, asymmetric encryption, key
                              agreement, and ASN.1 syntax in conjunction with elliptic curves.
                              PKCS #14 (Pseudorandom Number Generation Standard) is still
                              being developed. It will address many aspects of pseudo random
                              numbers.
                              PKCS#15 describes a file structure for chip cards in a PKI for
                              identification vis-à-vis various standards-aware applications
                              regardless of the application's cryptoki provider.
PKI Forum                     International committee for PKI issues (founded by manufacturers
                              in the USA).
                              TeleTrusT Germany has been a member since June 2000.
                              TCTrustCenter is also a member.
                              www.trustcenter.de
                              MailTrusT specification 2 based on S/MIME was introduced by
                              TeleTrust in the PKI forum.
                              www.teletrust.de (new URL:
                              http://212.185.192.36/default.asp?hi=1)
                              www.pkiforum.org
                              See also the European e-business committee EEMA – European
                              Forum for E-business (www.eema.org)
                              The PKI Challenge launched by the EEMA
                              www.eema.org/pki-challenge
                              in which TeleTrusT Germany is involved, is the largest European
                              PKI interoperability project.
Policy, PKI                   A security concept comprises organizational and technical measures
                              and is generally stipulated in a security policy.
                              The Public Key Infrastructure is stipulated in a PKI policy and
                              describes the organizational rules and technical components and
                              explains how they interact. The PKI Policy is the central document
                              of a PKI and defines the security level of the PKI. Certificates and
                              security measures must be documented in such a way that they can
                              be reconstructed. Certain criteria are crucial for transitions from one
                              PKI to another to establish mutual confidence and can, in certain
                              cases, even be automated.
                              A Certification Practice Statement must also be drawn up,
                              particularly if different certificate structures are involved (e.g.
                              signature and encryption).
                              The Digital Signature Act or Digital Signature Ordinance-compliant
                              audits to section 13 of the Digital Signature Act and section 15 of
                              the Digital Signature Ordinance includes documentation of the
                              security measures.
Private key                   Symmetric cryptography is based on a secret key which is owned by


ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                      56


                              both communication partners.
                              In asymmetric cryptography, each participant has a public key and a
                              private key.
                              The private key is used to sign the document and the public key to
                              check (validate) the signature.
                              Using the private key, the recipient can decrypt the message
                              encrypted with the public key of the recipient (see also public key
                              cryptography).
Public key                    The public key is the generally accessible part of a key pair that is
                              used in asymmetric cryptography.
Public key cryptography       Encryption method in which 2 different keys are used to encrypt and
                              decrypt a message (this explains the term asymmetric
                              cryptography).
                              In practice, one of these keys is published with the identification
                              data of the holder (= public key); the other key is made available to
                              the holder using a secure means (usually on a smart card) or is
                              generated on the smart card itself.
                              An important application of public key cryptography is the
                              electronic signature where a document is signed with the private key
                              after which the recipient then checks the signature with the public
                              key.
Public Key Infrastructure     PKI
                              The PKI groups together all the entities and processes that are
                              necessary for using public key cryptography.
                              They are usually described in a policy.
RA                            Registration authority, also called Local Registration Authority
                              (LRA)
                              Authority at which registration is carried out.
Registration                  Establishing the identity of a user in the personalization process at
                              an (L)RA and passing on the data (signed) to the Trust Center by
                              means of a secure channel. An application must have been
                              submitted for this purpose.
                              The participant involved in the procedure for digital signatures is
                              assigned a suitable and, as far as possible, unique name. This name
                              should be based on the standard X.520 for Distinguished Names.
                              According to the Digital Signature Act, it can be a pseudonym.
RegTP                         German regulatory authority for telecommunication and postal
                              services.
                              www.regtp.de
                              The RegTP is the root entity for qualified electronic signatures that
                              conform with the Digital Signature Act. The keys for the
                              Certification Authorities are certified with its original key.
Revocation                    Certificates can or must in certain cases be revoked by the owner,
                              holder or a third party before the period of validity comes to an end.
                              Possible reasons that necessitate revocation of a certificate include
                              disclosure of the Personal Security Environment (PSE), theft or loss
                              of the PSE or all cases in which misuse of a PSE must be suspected.
                              When a certificate is revoked, use of the certificate and the
                              associated PSE is permanently prevented because it is not possible
                              to reinstate a revoked certificate.
Revoking (a signature         Process used to identify the certificate as invalid (online) when the
certificate)                  signature is being checked/validated by the CA or replicated
                              information services.
                              The participant or his representative can have the certificate



ebIX                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                                        57


                               revoked. The card-issuing entity or the CA as the certificate-issuing
                               entity must act as a representative here. The revocation must contain
                               the time at which it was carried out and must not be retroactive.
                               Information is obligatory.
                               Further requirements regarding revocation management are defined
                               in the Digital Signature Act.
RSA algorithm                  RSA was introduced in 1977 by its inventors: Ronald Rivest from
                               MIT, Adi Shamir from the Weizmann Institute in Israel and
                               Leonard Adelman from USC. The name of the algorithm is based on
                               the initial letters of their last names. Its security is based on the
                               difficulty of factoring large integers.
                               At present, it normally uses key lengths of 1024 bits. According to
                               BSI specifications, the key length will have to be at least 2048 by
                               the middle of 2004. RSA is currently the most widely used crypto
                               algorithm for generating digital signatures using the public key
                               method. Other algorithms recommended by the BSI include DSA
                               and DSA with elliptical curves based on finite number fields. Due to
                               cut-backs in resources (key length), elliptical curves (EC) will be
                               used in future for higher levels of security.
S/MIME                         Secure Multipurpose Internet Mail Extensions
                               Enables e-mails to be sent and received securely and is based on the
                               MIME standard.
SECCOS                         Secure Chip Card Operating System of the ZKA. Asymmetric
                               cryptography is supported for the first time as of Version 5.0.
Security policy                Binding document that describes the security policy of a company.
                               Potential business risks are assessed and, where appropriate, suitable
                               measures are defined. Risks are unexpected negative events and
                               business opportunities that have not been realized. IT security is part
                               of the Security Policy; the PKI Policy is part of the Security Policy.
SET (Secure Electronic         SET specifies a secure protocol for credit card payments with the
Transaction)                   following services:
                               Authenticates the customer as the registered card holder,
                               authenticates the dealer as an authorized card receiving agent,
                               authenticates the clearing agencies and banks involved, guarantees
                               the integrity and confidentiality of the payment information
                               transmitted.
Signature Alliance             The German Signature Alliance was formed on April 3, 2003
                               between authorities and companies with the aim of promoting
                               electronic signatures. Terms of reference and convergence
                               objectives were elaborated for this purpose. The purpose of the
                               Signature Alliance is to promote the use, propagation and
                               introduction of chip-card-based electronic signatures and other PKI
                               applications. To this end, the members of the Alliance undertake to
                               develop a stable foundation for interoperable structures on the basis
                               of jointly accepted standards. Aspects which might influence the
                               propagation of electronic signatures are to be clarified in the course
                               of these efforts.
                               A distinction is made between two categories of signature
                               application:
                               - Applications of the qualified signature pursuant to the Digital
                               Signature Act which enable form-maintaining transactions and
                               - Applications of advanced signatures which are employed to ensure
                               authenticity and integrity.
Signature application of the   Contained in the interface specification for the ZKA chip card.



ebIX                                                                                  May 16, 2006
Technical PKI interoperability in the European energy sector                                      58


ZKA
Signature component           In general, a smart card with key material.
                              Usage in compliance with the Digital Signature Act is described in
                              the BSI signature interoperability specifications, section B2,
                              Signature component.
                              A distinction is made between five statuses:
                              Initialization status (Z0), authentication mechanism CA/PSE
                              Pre-personalization status (Z1), assignment of PSE participants
                              Key generation status (Z2) (keygen and safeguarding)
                              Personalization status (Z3) (up until certificate is loaded)
                              Control status (Z4) (signing possible)
Signature, accredited (in     Accredited signatures are qualified signatures, the issuer of which
Germany, signature that       (the certification authority) must have successfully completed an
conforms with the Digital     accreditation procedure in accordance with the Digital Signature
Signature Act)                Act.
                              Only the private key is signed by the RegTP.
                              www.regtp.de/gesetze/start/fs_04.html
Signature, qualified          Electronic signature with asymmetric cryptography, certificates and
electronic                    Public Key Infrastructure.
                              Conforms with the Digital Signature Act: 2-level hierarchy,
                              uppermost root entity is the RegTP.
Signature, simple and         Although the terms “simple” and “advanced” signatures have been
advanced                      defined, they are not regulated in any way and can be used as
                              required (this includes, for example, the widely-used Pretty Good
                              Privacy method (PGP)).
Signatures, qualified         According to the wording of the guideline, these are “advanced”
                              signatures created with a secure signature creation device and which
                              are at the disposal of the holder only.
                              Qualified electronic signatures with provider accreditation are those
                              signatures that are equivalent to a manual signature within the scope
                              of the Form Adjustment Act.
Single sign on                Provisions and mechanisms that allow a user to authenticate himself
                              just once vis-à-vis a system yet gain access to other processes and
                              resources.
Smart card                    Minicomputer the size of a credit card. The card is equipped with a
                              chip (mounted on a module) containing a processor, data memory
                              (file system) and an operating system. One important feature of the
                              operating system is the integrated access protection for data in the
                              file system. The user must enter a correct pin or authenticate himself
                              in order to achieve the appropriate access status so that the data in
                              the file can be made accessible to the outside world. The processor
                              also performs cryptographic arithmetic operations autonomously. A
                              crypto co-processor is required for cryptographic operations in
                              security-critical applications, the bus width of which should be
                              greater than the key length (for example, 1100 bits with 1024 bit
                              RSA keys). The key length defines the modulus n=p q (p,q prime
                              numbers) in the RSA procedure.
                              The chip used must (in Germany) be certified to ITSEC E4 Hoch;
                              that is, a test laboratory accredited by the BSI has performed black
                              box tests (for example, different time responses of cryptographic
                              operations) and, following disclosure of the infrastructure of the
                              chip, white box penetration tests (microprobing, Bellcore attacks,
                              and so on) and did not establish any weaknesses with regard to the
                              attacks defined for level 4 "Hoch". The infrastructure of the chip is



ebIX                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                                       59


                              disclosed right down to the circuit diagram level and physical
                              layers.
Soft PSE, software PSE        Personal Security Environment (in particular, private keys) which is
                              stored on diskette and not on non-readable hardware (chip card), or
                              is sent to the key holder by e-mail.
SPHINX                        In the SPHINX pilot project, products from various manufacturers
                              are tested in order to achieve end-to-end security in public
                              authorities. Selected workstations are equipped with a chip card
                              reader and security software.
                              Deploying the manufacturer-neutral standard MailTrusT from
                              TeleTrust e.V. ensures that products from different manufactures
                              can communicate with each other.
                              The key material required is made available in a pilot Public Key
                              Infrastructure. This is set up and operated for SPHINX at the BSI
                              and Competence Center Informatik GmbH.
                              The Public Key Infrastructure comprises three certification entities.
                              These use certificates to ensure the authenticity of the public keys
                              and the identity of the owner. SPHINX supports both central and
                              local key generation. The key material is stored on chip cards or on
                              diskette.
                              Objectives of the SPHINX pilot project:
                              To test the cross-product interoperability of solutions from different
                              vendors
                              To establish the extent to which the products are accepted by users
                              To determine the outlay for implementing products tested within
                              SPHINX in public authorities.
                              Details of the experience gathered so far from implementing the
                              interoperability requirements in a real-world environment have been
                              published.
                              sphinx@bsi.bund.de and
                              www.bsi.bund.de/aufgaben/projekte/sphinx/index.htm
SSL (Secure Socket Layer      Protocol for encrypting messages on the Internet. SSL can be used
for TCP/IP)                   in conjunction with the application programs SMTP, Telnet, FTP
                              and HTTP and is based on TCP / IP. The protocol was developed by
                              Netscape and uses complex 128-bit encryption for the data
                              transferred on the Internet. SSL encodes the data with public keys
                              that are confirmed by a third party in accordance with the X.509
                              standard. The high level of security is guaranteed by the fact that the
                              key used for decryption has to be specified separately and is stored
                              only for the user (that is, it is not transferred on the Internet); see
                              also TLS.
Time stamp service            TSS, Time Stamp Service.
                              In addition to document integrity, which is confirmed by means of a
                              signature, time-related integrity is often relevant from a legal
                              perspective.
                              This is achieved by means of a time stamp which takes the form of a
                              certificate signed by the time stamp service. The Digital Signature
                              Act does not specify any requirements regarding the time source or
                              time zone. All that is important is that no ambiguity prevails. A time
                              stamp is enforceable when the time is of considerable importance.
                              UTC time (Universal Time Coordinated) is normally used. This
                              corresponds to Greenwich Mean Time (GMT) and is represented in
                              15 bytes.
                              The time stamp service is generally a participant in its own CA.
                              Manufacturer note:


ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                     60


                              Products are available and are also used outside the PKI (for
                              example, from Utimaco for receiving lottery tickets electronically).
                              www.timeproof.de
TLS, Transport Layer          The encryption method TLS is an advanced version of SSL. TLS is
Security                      used to encrypt mails and uses certificate-based authentication to
                              monitor the integrity of mails and to prevent authorized access to
                              the mail server.
Token, cryptographic          Key memory used for accessing a secure area. Applications can
                              access an external device (cryptographic token) via a common
                              logical view. A distinction is made between hardware tokens and
                              soft tokens. Hardware tokens include smart cards, USB tokens, and
                              hardware security modules (HSM). Soft tokens are usually
                              generated in PKCS#12 format. The neutralizing interface is often
                              PKCS#11. Cryptoki (Cryptographic Token Interface) is an interface
                              defined in PKCS #11 for exchanging cryptographic data.
Trust Center, TC              Entity entrusted with the possible tasks of generating key pairs, the
                              safekeeping of key material, as well as issuing, publishing and
                              withdrawing public key certificates. See also BSI signature
                              interoperability specifications, section A5, Directory service.
Users of cryptographic         Person (also: end user): Employee, student trainee, apprentice,
methods in the PKI            consultant (working in a company or for a business partner)
                               Organization: Project group (within or outside the company),
                              administrative department, business partner company, and so on.
                               Process: Service, client, server, certification authority, LRA, and
                              so on.
                               Equipment: Computer, router, firewall, and so on.
                               A user such as this is either the user of a Personal Security
                              Environment (PSE) or a certificate, or is himself the purpose for
                              which certificates are used.
Verify, verification,         When a digital signature is verified, a check is carried out to
validation                    determine whether the signed data has been falsified and to establish
                              that it originates from the person, organization, process or device
                              that created the digital signature.
Visualization                 In this context: authentically displayed document which is to be
                              signed.
                              Refer to the BSI catalog of measures, Version 1.0 of November 18,
                              1997, p. 175 ff text, section16(3) with an interpretation of the BSI
                              and
                              The catalog of measures for technical components in accordance
                              with the Digital Signature Act, as at: July 15, 1998, chapter 3.
                              Published by the German regulatory authority for
                              telecommunication and postal services (RegTP).
WTLS (Wireless Transport      WTLS is a security protocol that resides in the WAP protocol
Layer Security)               architecture above the transport layer and provides confidentiality
                              (encryption), data integrity and authentication (of the terminal
                              equipment) for the application layer above. WTLS is not only the
                              counterpart of SSL/TLS in the Internet (TCP/IP) protocol
                              architecture but is in fact derived from SSL/TLS.
                              A distinction is made between WTLS Class 2 and WTLS Class 3.
                              Both use the WAP Identity Module (WIM) to carry out their
                              functions. WTLS Class 2 offers 2-phase security and end-to-end
                              security at the transport layer (Transport Layer Security). WTLS
                              Class 3 is the same as WTLS Class 2 and also supports user
                              authentication at the application layer. WTLS Class 3 uses the



ebIX                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                                     61


                              WMLScript function signText for this purpose.
X.500                         CCITT recommendation for directory system/directory services.
                              www.ietf.org/rfc/rfc1309.txt
                              Each object known to the directory service is represented by means
                              of an entry in the Directory Information Base. These requirements
                              are fulfilled in the X.500 standard in that the hierarchical
                              dependencies are transferred to the entries by means of a tree
                              structure (Directory Information Tree). This tree structure enables
                              each entry to be assigned uniquely to a higher-level entry.
                              According to the data distribution concept in the X.500 standard, the
                              Information Base can be distributed among any number of systems.
                              Each system features an application process, the Directory System
                              Agent (DSA), which accesses the part of the Directory Information
                              Base that it manages. A directory user is represented by a user
                              agent, the Directory User Agent (DUA) – this is similar to an
                              electronic mail system based on X.400. The directory model to
                              X.500 includes functions for checking the identity of a user. Two
                              authentication levels are provided. Simple authentication is based on
                              simple password verification, while strong authentication uses
                              encryption based on the public key method. The directory system,
                              which is generally known under the name Directory Services (DS)
                              is also referred to as ITU recommendation X.500 and ISO standard
                              9594.
X.509                         CCITT recommendation for the Directory Authentication
                              Framework.
                              V1 contains binding fields, V2 and V3 are defined in relatively
                              general terms and are specified in greater detail within the
                              framework of the interoperability requirements.
X.520                         See Distinguished Name
XML DSIG                      XML Extensible Markup Language
                              An open standard which now enjoys wide acceptance
                              Allows content to be separated from its presentation form
                              Is text based
                              Is self descriptive
                              Can be extended
                              Can be internationalized
                              Is platform and language neutral
                              Can be processed automatically
                              Is suitable for long-term data storage
                              Can be easily transformed
                              Provisions for the digital signature of XML documents are specified
                              in RFC 3075.
                              There are three versions (enveloping, enveloped, detached
                              signature).
                              www.dsml.org
                              DSML is an effort to establish a standard for combining LDAP with
                              XML.
ZKA                           Central loans committee of the German banking industry.
                              The money cards issued are bank cards with a chip based on
                              symmetric cryptography. The chip operating system used has been
                              enhanced considerably (SECCOS) as a result of asymmetric
                              cryptography and includes mechanisms that support electronic
                              signatures.




ebIX                                                                                May 16, 2006

								
To top