Application of Electronic Signatures Technical Guideline

kitlunchroomΤεχνίτη Νοημοσύνη και Ρομποτική

21 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

136 εμφανίσεις
















CEN/ISSS WS/BII
-
2



Application of
Electronic Signatures


Technical Guideline























Version
: 0.3




Released:

2012
-
05
-
07




Date of approval:




Page
2

BII xxx


TABLE
OF CONTENTS

1

Preamble

................................
................................
................................
................................
....

3

2

Introduction

................................
................................
................................
................................

4

3

Electronic signatures

................................
................................
................................
..................

5

3.1

What is an electronic signature?

................................
................................
............................

5

3.2

Uses of electronic signatures

................................
................................
................................
.

8

3.3

Advanced electronic signatures

................................
................................
..............................

9

3.4

Qualified signatures

................................
................................
................................
...............

9

3.5

Categories of XML electronic signatures

................................
................................
................

9

3.6

XML Signature Standards

................................
................................
................................
....

10

4

Requirements for applying electronic signatures

................................
................................
......

12

5

Recommendations for applying electr
onic signatures

................................
...............................

13

Page
3

BII xxx


1


Preamble

The objective of the second phase of the CEN Workshop on Business Interoperability
Interfaces for public procurement in Europe


C
EN WS/BII2


is to provide a framework for
interoperability in pan
-
European electronic procurement transactions, expressed as a set
of technical specifications that cross
-
refer to relevant activities, and in particular are
compatible with UN/CEFACT
-

in or
der to ensure global interoperability. The workshop is
focusing on implementation facilitations and co
-
ordinating pilots implementing the technical
specifications output. The requirements and final specifications are input into UN/CEFACT.

The original CEN
ISSS BII workshop was concluded in December 2009, and its results
were issued as CWA 16073:2010.


In early 2010, a second Workshop


CEN BII2


was
initiated to follow up on and improve the work created in the first workshop. The purpose of
the second phas
e of the workshop on Business Interoperability Interfaces for public
procurement in Europe is to establish a forum for development and governance, by:



Providing technical support for adopters and implementers of the BII
deliverables;



Providing a forum for
governance, life cycle management and further
refinements of the CWA published by CEN WS/BII;



Contributing to coordination and harmonization amongst European initiatives
addressing various aspects of e
-
procurement;



Actively cooperating with the relevant or
ganisations to ensure that European
requirements are catered for in international standards and initiatives.

Page
4

BII xxx


2

Introduction

The purpose of this document is to provide a technical
guidance

on how to
apply
electronic
signature
s
in
business documents

when needed
.
It is not the purpose of this document to
define the situations where economic operators or contracting authorities have to apply
electronic signature
s. This is a legal issue that has to be further developed at legal level.

Nevertheless, e
ven

using paper, some documents exchanged
during

public procurement
processes
require the signature of
the

issuer
. A signed document is used

to commit

the
signatory

to the contents of the exchanged document.
There are several documents
in
public procurement
t
hat
can potentially

require a signature:
A tender document, a
certificate or
a notification of awarding requires

the signature of
a

relevant
person.
Som
etimes
a signature is used to commit an organization to deliver the offered products or
services followi
ng the conditions stated in
a

tender
, other times

the signature is a proof of
authenticity, to ensure the issuer
has enough rights to issue it
.


G
uaranteeing the authenticity of the issuer, the integrity of the
message

and avoiding
repudiation of
its

conte
nts by the submitter

are requirements that
must be preserved

when
moving

from paper to electronic processes
.

T
here are
several
technical tools

and standards that allow XML documents to be
digitally
signed.

T
his report

will
focus on XML

standards

for
electr
onic signature
s

and
will explain
the way they can be applied to
CEN BII2

conformant
document instances.

CEN BII2 is syntax neutral

and the application of
electronic signature
s
is

syntax
-
specific
,
therefore

this report will
define

of a set of high
-
level requirements and a brief
recommendation on how to apply
these
electronic signature
s to XML
-
based documents
.
The type of signature and its format to be used when signing XML documents must be
based on recommendations from the European Commision to lev
erage interoperability
.

Page
5

BII xxx


3

Electronic signature
s


3.1

What is a
n

electronic signature
?

A
n

electronic signature

is a mathematical scheme for demonstrating the authenticity of a
digital message or document.

The EU Directive
1

describes the electronic signature as
“data in electronic form which are attached to or logically associated with other electronic
data and which serve as a method of authentication.”



A valid
electronic signature

gives a recipient
a
reason to believe that a known sender
created the message,
and that it was not altered
while exchanged
.

There are several ways of digitally signing a
n electronic

message. All
of
the
m

are based
on a
key
, a
digest

of the message and an
encryption algorithm

to encrypt the
digest
.

T
he encrypted digest

is the
electronic signature
.


Mathematically,
signing a message

is the result of applying an encryption
algorithm with a
key to the

message digest.

The message digest is the product of applying

a hash function
to the message
.




Figure
1

Signature process

To verify a
n

electronic signature
, the receiver has to calculate the message digest again,
and compare it to the result of decrypting the
electronic signature
.




1

EU DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999

Page
6

BII xxx



Figure
2

Verification process

3.1.1

Message digest

The s
ender creates a digest of the document using a mathematical algorithm. These
mathematical algorithms are known as hash functions, and they take a message of any
length as input, and output a short, fixed length
digest or
hash.

For good hash functions, it
is almost impossible to find two messages that produce the
same hash.

The result of applying a hash function to a file has several features:

1.

If the content

of the file change
s
, the resulting hash is different.

2.

It is impossible to recover the file contents

from the hash.

There is not an inverse
hash function.

3.

Applying the same hash function to the same message will always result in the
same hash.

Page
7

BII xxx


These features allow preserving the inte
grity of a message
:

If a signed message

is
modified
,
when
the receiver c
alculate
s the hash to verify
t
he signature
,
he will get a hash
different
from the hash
de
crypted using the signature algorithm and the
private

ke
y
.


3.1.2

Private

key

A

private

key

is a token used to encrypt the

message
hash

using
an

encryption algorithm
.

Bindi
ng the

private

key to a particular user is the ba
se for

authenticating the

identity
of the
signer

and
for avoiding
repudiation
of
his

authory
;

both

features implicit in
electronic
signature
s
.


If this key is bound to a person and no one

else can get access

to it, the receiver will trust
the signer has issued the signed document.

As described above, t
he receiver has to decrypt the encrypted hash in order to verify the
signature. To decrypt the encrypted hash,
the receiver

needs t
o get a
decryption key. This

key allows the receiver:



To get the original hash of the document, and compare it to the calculated hash to
ensure they a
re equal, verifying

the document

integrity
,



To ensure the
private

key owner issued the signature
, proving his identity as the
signer
and
preventing repudiation.


To

enable

encrypt
ion and decryption of

a
hash
, there are different types of cryptography:



Symmetric
-
key

cryptography: The same key is used to encrypt and to decrypt the
digest;

hence issuer and receiver need to share the key to

sign and verify the
signature.



Asym
m
etric
(or public key)

cryptography: Uses pairs of keys, one is kept secret and
is used to encrypt a hash

(sign)
, while the other is mad
e public and is used to
decrypt

the
hash (verify the
signature
)
.

A
symmetric cryptog
raphy is being widely adopted because the signer can keep the private
key
to create
electronic signature
s

whilst

publishing the public key for others to verify.

A
significant disadvantage of symmetric ciphers is the key management necessary to use
them sec
urely.

It is easier to publish a public key than sharing a
private

key as
required
in
the symmetric cryptography.

In asymmetric cryptography, t
he way a user publishes his public key can be done in

different ways:



Peer to peer
,
directly
sharing public keys

among

a community of
users
. The trust is
built
due to

personal

relationships; it is

based on the fact you trust on
your peer
.
T
rust relationships have
a network effect.



Public Key Infrastructure, where a third party acts as a trust maker. The third party
is known as Certification Authority and issues a certificate
. A certificate is the public
key of a user signed by the Certification Authority that has proven the identity of the
owner of the private key associated with the signed public key.
Trust is creat
ed as a
chain. A receiver trusts in the Certification Authority so it trusts
on

all the users that
h
ave a certificate issued by them
.


Page
8

BII xxx


As this token is secret and only known by the issuer of the signature, the recipient of the
signed message can believe on

the authenticity of the origin
of the signature if he can
decrypt it.


But the token, the private key, is a string of bits stored in a file. Even if
it

can be protected
with

a password,
to ensure th
at a

private key is only used by
its

owner
is one of the
most
important challenges in
electronic signature

processes
. Storing the private key in a
cryptographic hardware device such as an smartcard or a USB cryptographic token are
common ways to securely bind the user with his private key, nevertheless, even in
these
cases there are possibilities of loss of the device and impersonation.

3.1.3

Signature algorithms

There are
two main

algorithms related with
electronic signature
s:



A signing algorithm that, given a message and a pr
ivate key, produces a signature
(see figu
re 1 above).



A signature verifying algorithm that, given a message, public key and a signature,
either accepts or rejects the message's claim to authenticity

(see figure 2 above
)
.

Two main properties are required

for these two algorithm types:

1.

First, a sig
nature generated from a fixed message and fixed private key should
verify the authenticity of that message by using the corresponding public key.

2.

Secondly, it should be computationally infeasible to generate a valid signature for a
party who does not posse
ss the private key.


3.2

Uses of
electronic signature
s

Electronic signature
s in public procurement have different uses. When moving away from
paper documents with ink signatures or authenticity stamps,
electronic signature
s can
provide added assurances

such as identity, evidence of provenance, acknowledgment or
consent and approval.

C
ommon reasons for applying a
electronic signature

to

electronic
documents

are
described below
.

3.2.1

Authentication

Although messages may often include information about the entity sending a message,
that information may not be accurate.
Electronic signature
s can be used to authenticate
the source of
a message
. When ownership of a
n

electronic signature

private

key is bo
und
to a specific user

as explained above
, a valid signature shows that th
e message was sent
by that user
.


3.2.2

Integrity

In public procurement

business processes
, it is important to ensure that

the exchanged

message has not been altered during transmission.
W
hen a
message is
electronically

signed, any change in the message after signature will invalidate the signature.
Furthermore, there is no efficient way to modify a message and
regenerate the

signature
if
the attacker does not have access to the
private

key

of the original issuer.

Page
9

BII xxx


3.2.3

Non
-
repudiation

Non
-
repudiation

of origin

is an important
feature

of
electronic signature
s. By this property
an entity that has signed some information cannot at a later time deny having signed it.

3.3

Advanced
electronic signature
s


The European Directive
1999/93/EC defines
four

technology
-
neutral requirements that an
electronic signature must meet to be considered an Advanced Electronic Signature (AdES)
and have legal validity:



The signature has to be

uniquely linked to the signatory
;



It must be
capable of identifying the signatory;



It must be

created using means that the signatory can maintain under his sole
control; and



It must be

linked to the data to which it relates in such a manner that any
subsequent change of the data is detec
table.

3.4

Qualified signatures

A Qualified Signature is

defined as an AdES based on
a Qualified Certificate

and
issued
using a
Secure Sign
ature Creation Device (SSCD)
.

Qualified Certificates
are certificates

issued by
accredited Certificate Service Provider
s
.

An SSCD is defined by European Directive 1999/93/EC as a device that must, by
appropriate technical and procedural means, ensure:



The signature
-
creation data used for signature generation can occur only once, and
that
its

secrecy is reasonably assured.



The signature
-
creation data used for signature generation cannot, with reasonable
assurance, be derived and the signature is protected against forgery using currently
available technology.



The signature
-
creation data used for signature generation can be re
liably protected
by the legitimate signatory against the use of others.



Secure signature
-
creation devices must not alter data to be signed or prevent such
data from being presented to the signatory prior to the signature process.

European legislation makes

Qualified Signatures equivalent to handwritten signatures.

3.5

Categories of
XML
electronic signature
s

An XML signature may be described as detached, enveloping, or enveloped.



Detached
. The signature applies to
an
external

XML document that

can be
identified via a URI or transform. Consequently, the signature is "detached" from the
content it signs. This definition typically a
pplies to separate data objects
.

Page
10

BII xxx



Figure
3

Detached signature




Enveloping
. The signature ap
plies to content found within
an

element of the
signature itself.


Figure
4

Enveloping signature



Enveloped
. The signature applie
d

to the XML
document is contained in the XML
document itself
. Impleme
ntations of enveloped
signatures

must take care not to
include the signature in the calculation of the signature value.


Figure
5

Enveloped signature


3.6

XML Signature Standards

3.6.1

XMLDSig

XMLDSig
is a W3C
standard
that defines basic rules for creating and p
rocessing
electronic
signature
s of XML documents.

Page
11

BII xxx


The XMLDSig standard defines the XML structure
for expressing

the signature and related
data, the processes for signature creation and verification,
as well as

the accepted
algorithms for canonicalization a
nd transformation of data allowed.

The structure of an XMLDSig is as follows:

<Signature>


<SignedInfo>


<CanonicalizationMethod />


<SignatureMethod />


<Reference>


<Transforms>


<DigestMethod>


<DigestValue>


<
/Reference>


<Reference /> etc.


</SignedInfo>


<SignatureValue />


<KeyInfo />


<Object />


</Signature>



Where:

The
SignedInfo

element contains or references the signed data and specifies wha
t
algorithms are used when the signature has been
created.


The
CanonicalizationMethod

and
SignatureMethod

elements are used
to create
the
SignatureValue

element
(the actual signature)
and are included in
SignedInfo

to
protect them from tampering.

Within the
SignedInfo

element, o
ne or more
Reference

elements
can be defined to
specify the resource being signed by URI reference; and any
T
ransforms

to be applied
to the resource prior to signing.

DigestMethod

specifies the hash algorithm
that was applied to the document
.


DigestValue

contains the result of applying the hash algorithm to the transformed
resource
.

The
SignatureValue

element contains the Base64 encoded signature result
-

the
signature generated with the parameters specified in the
SignatureMethod

element
-

of
the
SignedI
nfo

after applying the algorithm specified by the
CanonicalizationMethod
.

KeyInfo

element optionally allows the signer to provide recipients with the key that
validates the signature, usually in the form of one or more X.509 digital certificates.

The
Objec
t

element
is optional and
contains the signed data if this is an enveloping
signature




Page
12

BII xxx


4

Requirements for
applying
electronic signature
s

High
-
level requirements for applying
electronic signature
s to CEN BII2
conformant
XML
document instances:

DS
-
1

A
n

electronic signature

must be applied to the whole XML document instance
(excluding the signature itself when using enveloped signature).

DS
-
2

The presence of
a
n

electronic signature

in a XML document instance
should not
add any constraints on processing

do
cument content.

DS
-
3

Whether a
n

electronic signature

exists in an XML document instance, personal
signatory data contained in the
electronic signature

will override signatory
metadata in the document instance
, if any
.

DS
-
4

Documents and their
electronic s
ignature
s
should

be kept tog
ether, ideally in a
single file, therefore enveloped signatures are recommended.

DS
-
5

Commission Decision on Signature Formats from February 2011:
http://eur
-
lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF

for XADES
-
BES/EPES must be followed.

ETSI ESI Technical Specifications
“Baseline Profiles” for XAdES
2

must be followed.





2

ETSI TS 103 17

Page
13

BII xxx


5

Recommendations for applying
e
lectronic signature
s


As per the requirements above, w
hen applying
electronic signature
s to XML instances, the
following recommendations should be
followed
:


Specification /
method

Recommendation

Supported
requireme
nt

Rational

Method of applying
a signature

Enveloped

DS
-
1

DS
-
2

DS
-
4

DS
-
5

A detached signature could
fulfil most of the
requirements

except DS
-
4
.
An enveloping signature
mandates the processing of
a signature object to extract
the document.

Validation

process

The p
la
ceholder
for
electronic signature
s
should have
an
attribute
processContents="
skip"

DS
-
2

DS
-
2

DS
-
4

The XSD schema validator
for the document must be
able to
skip

structure
validation of the
electronic
signature
.

Signature

format

Follow

EC and ETSI
recommendations
XAdES
-
BES/EPES
3

DS
-
3

DS
-
5

Refer to CEN
-
ETSI specific
standards and
recommendations.
4








3

http://eur
-
lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF

4

ETSI ESI is
currently
working on the EC standardisation Mandate 460 "Rationalised
framew
ork for electronic signature" to end up creating
European Norms

to harmonize t
he
use of electronic signatures in cross
-
border scenarios. As per Mandate 460, ETSI ESI is
describing the technical specifications fulfilling the EC Decision as “Baseline Profiles” for
all AdES signatures, and XAdES among them.
http://www.e
-
signatures
-
sta
ndards.eu/