Technical PKI interoperability in the European energy sector
1
PKI Policy
Recommendations to market participants
Status:
Version/release:
Revision:
Date:
ebIX
Request for comments
0.3
none
March 08, 2016
May 16, 2006
Technical PKI interoperability in the European energy sector
2
CONTENTS
0
MANAGEMENT SUMMARY .................................................................................................... 4
0.1
0.2
1
BACKGROUND ......................................................................................................................... 4
KEY RECOMMENDATIONS ........................................................................................................ 4
INTRODUCTION ......................................................................................................................... 6
1.1
1.2
1.3
1.4
1.5
ABOUT THIS DOCUMENT .......................................................................................................... 6
SCOPE OF PROJECT ................................................................................................................... 6
PARTICIPANTS IN THE PROJECT ............................................................................................... 6
REFERENCES ............................................................................................................................ 7
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
5.2
5.3
5.4
5.5
6
PRE-PERSONALIZATION ......................................................................................................... 23
PERSONALIZATION ................................................................................................................ 23
INITIAL SUPPLY OF SMART CARDS DURING THE IMPLEMENTATION PHASE ......................... 23
KEY GENERATION ON THE SMART CARD .............................................................................. 24
POST-PERSONALIZATION ....................................................................................................... 24
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
ebIX
CORPORATE DIRECTORY .................................................................................................... 35
May 16, 2006
Technical PKI interoperability in the European energy sector
APPENDIX A
A.1
A.2
A.3
A.4
A.5
3
REQUIREMENTS IN TABLE FORM ............................................................. 37
GENERAL REQUIREMENTS ..................................................................................................... 37
PKI COMPONENT ORGANIZATION ......................................................................................... 37
CREATING/STORING KEYS/CERTIFICATES ............................................................................ 37
PROCESSING KEYS IN CLIENT SOFTWARE ............................................................................. 38
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
C.1
C.2
C.3
SUMMARY OF REQUIREMENTS FOR DIRECTORY/REPOSITORY ... 42
REQUIREMENTS REGARDING VALIDATION ........................................................................... 42
SOLUTION PROPOSAL ............................................................................................................ 42
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 interoperability 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
Country
DE
DE
DK
BE
SE
NL
FI
NO
NO
SE
SE
CH
1.4
Name
Carl W. Major
Dr. Konstantin Staschus
Erik Hartwell
Hugo Dekeyser
Joachim Abrahmsén
Lodewijk ter Haar
Matti Vasara
Per M. Breistein
Ole Jacob Høyland
Oscar Ludwigs
Robert Lundin
Rudolf Baumann
7
Company
E.ON Netz
VDN
Energinet.dk
Eandis
Steria
Tennet
Fingrid
Statkraft
Statnett
Svenska Kraftnät
Steria
ETRANS
References
[1] Original project proposal, see http://www.ebix.org/
1.5
Ver.
0
0
0
ebIX
Change log
Rel.
1
2
3
Rev.
none
none
none
Date
2006-01-26
2006-02-28
2006-05-16
Changes
Document generated
Comments incorporated
Published as ebIX RFC
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 transportbound 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
3.2.1
Internet Business Scenarios
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
Verifiability of commnuication
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
3.2.4
13
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,
Quot.
Technical info.
etc.
Business with
partners based on
contracts or with
limited value
Business
with unknown
partners or with high
or limited value
B2B with
low-value
contract content
In legally necessary
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
settled through
goodwill
Claims
settled through
mutual agreement
or out-of-court
settlement
Claims
settled through
judicial decision or
arbitral award
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
3.2.5
15
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
persons
hold
User
certificates
Communication
components
hold
Component
certificates
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 email 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, crosscertification 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 subdifferentiation (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
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.
8
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 prepersonalization 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
Registration authority
remote
(many)
Firewall
Certification authority
Certificate
Smart card
management
Holder
Documentary
evidence verifying
identity
ebIX
Application for
certification
Corporate
directory
Certificate
directory
CRL
Key
generation
Time stamp
service
Certificate
generation
Key archive
Cert.
Operational CA
May 16, 2006
Technical PKI interoperability in the European energy sector
6.3
27
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.
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.
22
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
6.3.3
31
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).
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.
27
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
DIR server 1
Variant 2: Chaining Þ Distributed data storage
DIR server 2
DIR server 2
DIR server 1
Data copy
Link
Network
Network
Admin.
Admin.
Users
Admin.
Users
Users
• Central administration
• Periodic shadowing (automat. copy)
• Deployed in central organizational units
Original data
Users
• Local administration
• Distributed directory (log. 1 directory from
perspective of end user)
• Deployed in local organizational units;
predominantly local data is accessed
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.
2.
3.
4.
5.
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.
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.
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.
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.
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.
2.
3.
4.
5.
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.
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.
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.
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.
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.
ebIX
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.
May 16, 2006
Technical PKI interoperability in the European energy sector
2.
3.
4.
5.
6.
7
8.
9.
10.
11.
12.
13.
14.
15.
38
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.
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.
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.
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.
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.
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.
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.
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.
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.
A certificate that has been revoked cannot be reinstated. Advanced certificates can be suspended
for a set time under specially defined conditions.
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.
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.
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).
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.
2.
3.
4.
5.
6.
Cards are initialized by the CA.
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.
The key pairs for signing and identification purposes are generated on the
card itself.
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.
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.
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.
2.
The LRA informs the CA of the person the card is assigned to.
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.
2.
3.
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.
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.
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.
ebIX
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.
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.
2.
3.
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).
It must be possible to determine the user of a signature certificate.
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.
2.
3.
4.
5.
6.
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.
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.
The DN of the certificates comprises the last and first name of the user and a unique noninformative number as a global ID which is valid for at least 100 years. Further provisions are
specified in the recommendations for the certificate content.
If the user’s organizational assignment or name changes, the same unique number is retained. It
identifies the user permanently and uniquely.
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.
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.
2.
3.
4.
ebIX
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.
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.
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.
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.
May 16, 2006
Technical PKI interoperability in the European energy sector
ebIX
43
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
documents)
Asymmetric cryptography
Authentication
Bridge CA
BSI
Business terminal
ebIX
Archiving is defined by law in different ways. Examples from
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.
A mathematical data encryption procedure in which two different
mathematically related keys are used to encrypt and decrypt data.
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.
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
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.
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
May 16, 2006
Technical PKI interoperability in the European energy sector
CA
Certificate
Certificate user, relying
party, recipient, verifier
Chip card
Corporate directory
CRL
Crypto algorithm
ebIX
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
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
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.
These are persons, organizations, processes or devices that use the
certificate or the public key it contains for encryption (before the
data is sent) or verification (after the signed data has been received)
purposes.
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.
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.
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
Set of mathematical rules for carrying out cryptographic operations
(such as encryption and hashing) recursively on the basis of
May 16, 2006
Technical PKI interoperability in the European energy sector
CSP
DES
Digital signature
Digital Signature Act
Digital Signature
Ordinance
DIN standard, electr.
signature
Distinguished name
EESSI (European
Electronic Signature
Standardization Initiative)
ebIX
48
elementary mathematical functions (such as shift, multiplication,
calculate remainder) using keys and parameters.
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).
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.
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.
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
Ordinance for electronic signatures and for converting fees and
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 NI-17.4, Version 1.0, 15.12.1998, available at BSI,
www.bsi.bund.de.
Technical name of a directory entry.
In line with the CCITT recommendations X.520, Selected Attribute
Types.
Most important European standardization committee for digital
signatures.
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,
May 16, 2006
Technical PKI interoperability in the European energy sector
Encryption
Form Adjustment Act
GDPdU
Global Identifier (GID)
Hash algorithms
ebIX
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 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-toEnd): 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.
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).
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.
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.
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
May 16, 2006
Technical PKI interoperability in the European energy sector
Identrus
ISIS
ISIS-MTT
Key archive
Key backup
Key certificate
Key escrow
ebIX
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 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 (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 ISISMTT standard was adopted together with the Teletrust association.
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.
KA
Entity in the Trust Center responsible for key archiving, see also
Key Generation (KG).
“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.
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.
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
May 16, 2006
Technical PKI interoperability in the European energy sector
Key generation
Key holder
Key material
Key recovery
Key user
Key, key pair
LDAP
ebIX
51
account of the cryptographic export guidelines in other countries.
(See also the Wassenaar agreement).
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.
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.
Personal key material (Personal Security Environment) and the
associated (public) key certificate.
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.
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.
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.
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.500based 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
May 16, 2006
Technical PKI interoperability in the European energy sector
LRA
Maßnahmenkatalog für Dig
Sig (catalog of measures for
dig. sig.)
Message authentication
code
Message recovery
MeT (Mobile Electronic
Transaction Forum)
MoSign (Mobile Signature)
mSign (Mobile Electronic
Signature Consortium)
ebIX
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.
Local Registration Authority;
Authorized, user-oriented authority which identifies and
authenticates users and which manages and hands over the key
material to the users.
The central reference point for legal requirements according to the
German Digital Signature Act and their interpretation as well as
information on organizational and technical implementation.
www.bsi.de/fachthem/index.htm
MAC
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.
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.
The MeT was founded in April 2000 by Ericsson, Motorola and
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 egovernment 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
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
The mSign consortium was founded at the end of 1999 by Brokat
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
May 16, 2006
Technical PKI interoperability in the European energy sector
OCSP
Operator, of a PKI IT
system
Owner, key owner
PC/SC interface
PEM
Personal key
Personal key, private key
Personal Security
ebIX
53
Radicchio formed a strategic partnership in February 2001.
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.
An operator within the meaning of this policy is the operator of an
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.
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.
The personal computer/smart card interface is a software
architecture with application programming interfaces that allow
applications to work with smart cards.
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.
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.
The private key is the secret part of the key pair (of a personal key
or function key) that is used in asymmetric cryptography.
PSE
May 16, 2006
Technical PKI interoperability in the European energy sector
Environment
Personalization
PGP
PIN
PIN, Personal Identity
Number
PKCS
ebIX
54
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.
Personal data consolidated to form card data.
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.
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.
The PIN is a password with which an end user authenticates himself
when he accesses the Personal Security Environment. The PIN is
used to protect the PSE, in particular the private key it contains.
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 DiffieHellman 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
May 16, 2006
Technical PKI interoperability in the European energy sector
PKI Forum
Policy, PKI
Private key
ebIX
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.
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.
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.
Symmetric cryptography is based on a secret key which is owned by
May 16, 2006
Technical PKI interoperability in the European energy sector
Public key
Public key cryptography
Public Key Infrastructure
RA
Registration
RegTP
Revocation
Revoking (a signature
certificate)
ebIX
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).
The public key is the generally accessible part of a key pair that is
used in asymmetric 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.
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.
Registration authority, also called Local Registration Authority
(LRA)
Authority at which registration is carried out.
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.
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.
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.
Process used to identify the certificate as invalid (online) when the
signature is being checked/validated by the CA or replicated
information services.
The participant or his representative can have the certificate
May 16, 2006
Technical PKI interoperability in the European energy sector
RSA algorithm
S/MIME
SECCOS
Security policy
SET (Secure Electronic
Transaction)
Signature Alliance
Signature application of the
ebIX
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 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.
Secure Multipurpose Internet Mail Extensions
Enables e-mails to be sent and received securely and is based on the
MIME standard.
Secure Chip Card Operating System of the ZKA. Asymmetric
cryptography is supported for the first time as of Version 5.0.
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 specifies a secure protocol for credit card payments with the
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.
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.
Contained in the interface specification for the ZKA chip card.
May 16, 2006
Technical PKI interoperability in the European energy sector
ZKA
Signature component
Signature, accredited (in
Germany, signature that
conforms with the Digital
Signature Act)
Signature, qualified
electronic
Signature, simple and
advanced
Signatures, qualified
Single sign on
Smart card
ebIX
58
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)
Accredited signatures are qualified signatures, the issuer of which
(the certification authority) must have successfully completed an
accreditation procedure in accordance with the Digital Signature
Act.
Only the private key is signed by the RegTP.
www.regtp.de/gesetze/start/fs_04.html
Electronic signature with asymmetric cryptography, certificates and
Public Key Infrastructure.
Conforms with the Digital Signature Act: 2-level hierarchy,
uppermost root entity is the RegTP.
Although the terms “simple” and “advanced” signatures have been
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)).
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.
Provisions and mechanisms that allow a user to authenticate himself
just once vis-à-vis a system yet gain access to other processes and
resources.
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
May 16, 2006
Technical PKI interoperability in the European energy sector
Soft PSE, software PSE
SPHINX
SSL (Secure Socket Layer
for TCP/IP)
Time stamp service
ebIX
59
disclosed right down to the circuit diagram level and physical
layers.
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.
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
Protocol for encrypting messages on the Internet. SSL can be used
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.
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:
May 16, 2006
Technical PKI interoperability in the European energy sector
TLS, Transport Layer
Security
Token, cryptographic
Trust Center, TC
Users of cryptographic
methods in the PKI
Verify, verification,
validation
Visualization
WTLS (Wireless Transport
Layer Security)
ebIX
60
Products are available and are also used outside the PKI (for
example, from Utimaco for receiving lottery tickets electronically).
www.timeproof.de
The encryption method TLS is an advanced version of SSL. TLS is
used to encrypt mails and uses certificate-based authentication to
monitor the integrity of mails and to prevent authorized access to
the mail server.
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.
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.
 Person (also: end user): Employee, student trainee, apprentice,
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.
When a digital signature is verified, a check is carried out to
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.
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 is a security protocol that resides in the WAP protocol
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
May 16, 2006
Technical PKI interoperability in the European energy sector
X.500
X.509
X.520
XML DSIG
ZKA
ebIX
61
WMLScript function signText for this purpose.
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.
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.
See Distinguished Name
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.
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.
May 16, 2006