An Implementation-independent Evaluation Model for Server-based

Signature Solutions

Thomas Zefferer and Bernd Zwattendorfer

Institute for Applied Information Processing and Communications, Graz University of Technology,

Inffeldgasse 16a, 8010 Graz, Austria

Keywords:

Electronic Signatures, Server-based Signature, Security Evaluation, Evaluation Model.

Abstract:

During the past years, a general trend towards server-based signature solutions can be observed. Server-based

signature solutions rely on a secure central server component that is able to securely store cryptographic keys

and to create electronic signatures on behalf of users. Due to their various advantages compared to client-based

solutions, it must be expected that server-based signature solutions will be increasingly deployed in security-

critical ﬁelds of application in future. This raises the need for appropriate means to systematically evaluate the

security of such solutions. Unfortunately, existing evaluation methods (e.g. Protection Proﬁles according to

Common Criteria) are only partly applicable for evaluating server-based signature solutions. To overcome this

issue, we propose a new implementation-independent evaluation model for server-based signature solutions.

The proposed evaluation model is based on an abstract architectural model for server-based signature solutions

and can hence be applied to arbitrary implementations. This way, we provide a powerful instrument to assess

the security of future server-based signature solutions and pave the way for their adoption in security-critical

ﬁelds of application.

1 INTRODUCTION

Electronic signatures have evolved to be an important

instrument in online services. Depending on the given

legal and organizational framework, the technical re-

alization and implementation of electronic signatures

is often no trivial task. For instance, in the Euro-

pean Union (EU) the EU Signature Directive (Euro-

pean Union, 1999) deﬁnes strict requirements for the

creation of qualiﬁed electronic signatures, which are

legally equivalent to handwritten signatures.

Considering European law, two basic approaches

can be followed to implement solutions for the cre-

ation of qualiﬁed electronic signatures. Client-based

signature solutions rely on a signature-creation token

that is possessed, controlled, and maintained by the

user, i.e. the signatory. Contrary, server-based signa-

ture solutions rely on a secure central server compo-

nent that is able to store cryptographic keys and to cre-

ate qualiﬁed electronic signatures on behalf of users.

During the past years, client-based signature so-

lutions relying on smart cards have been the pre-

ferred implementation option especially for security-

critical application scenarios. Unfortunately, client-

based signature solutions usually lack an appropriate

level of usability. This often leads to unsatisfactory

user acceptance for applications based on qualiﬁed

electronic signatures. Server-based signature solu-

tions have the potential to overcome usability-related

limitations of client-based approaches. An example is

the server-based signature solution that has been in-

troduced in Austria in 2010 (A-Trust, 2010). A con-

ducted usability analysis has shown that this solution

clearly outperforms existing client-based solutions in

terms of user acceptance (Zefferer and Krnjic, 2012).

Furthermore, this solution shows that server-based so-

lutions are able to comply with existing legal and or-

ganizational requirements.

Due to the given advantages of server-based signa-

tures, it can be expected that there will be an increas-

ing number of server-based signature solutions in fu-

ture. Hence, new server-based signature solutions

will also be deployed in security-critical ﬁelds of ap-

plication. This raises the need for appropriate means

to systematically evaluate the security of server-based

signature solutions in order to assess their suitability

for security-critical ﬁelds of applications. Approved

evaluation methods for signature solutions such as

Common Criteria (Common Criteria, 2013) are al-

ready available. However, most of these methods are

302

Zefferer T. and Zwattendorfer B..

An Implementation-independent Evaluation Model for Server-based Signature Solutions.

DOI: 10.5220/0004839603020309

In Proceedings of the 10th International Conference on Web Information Systems and Technologies (WEBIST-2014), pages 302-309

ISBN: 978-989-758-023-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

only partly applicable for server-based signature so-

lutions, as they usually do not properly consider their

special characteristics.

To overcome this issue, we propose a new

implementation-independent evaluation model for

server-based signature solutions. The proposed eval-

uation model is based on an abstract architectural

model for server-based signature solutions and can

hence be applied to arbitrary implementations that

comply with this architectural model. This way, we

provide a powerful instrument to assess the security

of future server-based signature solutions in order to

assure their suitability and applicability in security-

critical ﬁelds of application.

The remainder of this paper is structured as fol-

lows. In Section 2, basics of and related work on

server-based signature solutions are discussed and

their growing importance is emphasized. In Section 3,

a generic architectural model for server-based signa-

ture solutions is introduced. Based on this model, the

methodology that has been followed to develop the

evaluation model proposed in this paper is presented

in Section 4. Based on the presented methodology,

an evaluation model for server-based signature solu-

tions is developed and presented in Section 5. Finally,

conclusions are drawn in Section 6.

2 SERVER-BASED SIGNATURES

The idea to rely on a trusted server component for the

creation of electronic signatures on behalf of users is

not new. Early concepts of server-based signature so-

lutions have for instance been proposed in (Ding et al.,

2002), (Bicakci and Baykal, 2003), and (Bicakci and

Baykal, 2005). In general, server-based signature so-

lutions have various advantages compared to client-

based approaches. As computationally complex cryp-

tographic operations are implemented by a server

component, users do not need to acquire and main-

tain additional hardware or software in their client do-

main that is able to accomplish this task. Furthermore,

server-based signature solutions can also be conceptu-

ally beneﬁcial in terms of security, if security-critical

cryptographic operations are carried out in a protected

central environment such as a highly secure data-

processing center.

Despite their conceptual advantages, server-based

signature solutions have previously led a niche ex-

istence especially in security-critical application sce-

narios. The focus on client-based approaches in Eu-

rope was mainly caused by the EU Signature Direc-

tive (European Union, 1999), which deﬁnes the legal

basis for electronic signatures in EU Member States.

The EU Signature Directive deﬁnes that so-called ad-

vanced electronic signatures and qualiﬁed electronic

signatures, which are legally equivalent to handwrit-

ten signatures, must be ’created using means that the

signatory can maintain under his sole control’ (Euro-

pean Union, 1999). For several years, there has been

common consent that this passage implies the use of

user-owned signature-creation devices such as smart

cards, even though this has never been explicitly pos-

tulated by this directive.

First discussions on alternative interpretations of

the EU Signature Directive have been started in a

Public Statement on Server Based Signature Services

published by the Forum of European Supervisory Au-

thorities for Electronic Signatures (FESA)

. This doc-

ument explicitly supports the idea that server-based

signature solutions comply with the requirements de-

ﬁned by the EU Signature Directive (Forum of Eu-

ropean Supervisory Authorities for Electronic Signa-

tures, 2005). In 2010, a server-based signature solu-

tion that supports the creation of qualiﬁed electronic

signatures has been introduced and deployed in Aus-

tria (A-Trust, 2010). This solution has been based on

a concept discussed in (Orthacker et al., 2010) and

shows that server-based signature solutions are indeed

feasible and applicable in security-critical application

scenarios.

The growing importance of server-based signa-

ture solutions is also considered by legislative bod-

ies and standardization committees. Documents pub-

lished e.g. by the European Committee for Standard-

ization (CEN) (European Committee for Standardiza-

tion, 2013) and the European Commission (European

Union, 2012) already take the possibility of server-

based signature solution into account. The recent de-

velopment of productive server-based signature solu-

tions and the ongoing work on related standards and

legal frameworks in Europe show that server-based

signature solutions can be expected to further gain im-

portance in the near future.

In order to provide appropriate means and meth-

ods to systematically evaluate the reliability and

security of such solutions, we propose a new

implementation-independent evaluation model for the

security assessment of server-based signature solu-

tions. To achieve implementation independence, the

proposed evaluation model bases on a generic archi-

tectural model for server-based signature solutions,

which is introduced in the following section.

http://www.fesa.eu

AnImplementation-independentEvaluationModelforServer-basedSignatureSolutions

303

3 ARCHITECTURAL MODEL

The evaluation model proposed in this paper focuses

on solutions that require users to authorize signature-

creation processes by means of a two-factor authen-

tication. These solutions have gained importance

during the past years, as they are able to provide

the same level of security as client-based signature-

creation methods relying on two factors. Server-based

signature solutions relying on two-factor based user

authentication typically make use of a secret pass-

word to cover the authentication factor knowledge and

of one-time passwords (OTP) being sent to a device

owned by the legitimate user

. By proving reception

of the OTP, the user proves control over the device,

which in turn implements the authentication factor

possession.

An abstract model for a server-based signature so-

lution that relies on the delivery of OTPs to imple-

ment two-factor based user authentication is shown

in Figure 1. This model comprises two core compo-

nents. The System under Evaluation (SuE) comprises

all components of the server-based signature solution

that are subject to the evaluation model proposed in

this paper. The server-based signature solution itself

makes use of and interacts with several external com-

ponents. These components are subsumed under the

abstract component Environment.

Figure 1: System model.

The SuE basically consists of three components.

The Signature Server is the central component, which

implements most functionality and interacts with

external components, i.e. with the Environment,

through well-deﬁned interfaces. The Signature Server

uses a Database to store required data such as user-

related and user-identifying information. Addition-

ally, the Signature Server uses a Hardware Security

Module (HSM) to securely store security-critical data

Other approaches to realize two-factor based user au-

thentication are basically feasible. However, OTP-based ap-

proaches are currently wide-spread and already used in pro-

ductive signature solutions such as (A-Trust, 2010). Hence,

the evaluation model proposed in this paper focuses on

OTP-based solutions only.

(e.g. signing keys) and to carry out cryptographic op-

erations in a secure environment.

The Environment basically comprises three enti-

ties. The Signatory is the end user, who aims to cre-

ate an electronic signature using the SuE. Users usu-

ally need to register once at the SuE prior to using

its signature-creation functionality. During registra-

tion, a cryptographic key pair is generated by the SuE

(more precisely by the HSM). While the private key

remains at the SuE, the public key is sent to the Certi-

ﬁcation Authority (CA), which issues a signing cer-

tiﬁcate for the Signatory. This certiﬁcate links the

Signatory’s identity to the generated key pair. After

successful completion of the registration process, the

Signatory can use the SuE to create electronic signa-

tures.

To start a signature-creation process, the Signa-

tory sends the Data to be Signed (DTBS) to the Sig-

nature Server. Before creating the signature, the Sig-

nature Server requests the Signatory to enter a secret

password. Additionally, the Signature Server gener-

ates an OTP and transmits the OTP to the OTP Gate-

way. The OTP Gateway delivers the OTP to the Sig-

natory. By entering the received OTP at the Signature

Server, the Signatory completes the two factor-based

user authentication process. After successful user

authentication, the Signature Server loads required

Signatory-related data from the Database and com-

putes the electronic signature on the received DTBS

in the HSM. Optionally

, the Signature Server also

displays the DTBS to the Signatory and requests an

additional conﬁrmation from the Signatory to sign

these data. The computed signature is ﬁnally returned

to the Signatory.

Based on this implementation-independent archi-

tectural model we propose an evaluation model for

server-based signature solutions. The methodology

followed to develop the proposed evaluation model is

discussed in the next section.

4 METHODOLOGY

To rely on an approved method and to follow a

systematic approach, we have based our evaluation

model for server-based signature solutions on the con-

cepts of Common Criteria (Common Criteria, 2013)

and on the Protection Proﬁle for Secure Signature

Creation Devices (SSCD) Type 3 (CEN/ISSS, 2001).

Development of security recommendations along the

concepts of Common Criteria and Protection Proﬁles

In most cases, the applied legal framework determines

whether DTBS must be displayed to the user during the

signature-creation process or not.

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

304

is common practice. For instance, the Council of Eu-

rope has applied this methodology in the context of a

risk analysis for e-voting solutions (European Coun-

cil, 2004).

As Common Criteria in general and the Protection

Proﬁle for Secure Signature Creation Devices (SSCD)

Type 3 in particular have not been developed with

server-based signature solutions in mind, we have

adapted underlying concepts where necessary to tai-

lor our model to the special characteristics of server-

based signature solutions. The resulting methodology

that has been followed to develop the proposed eval-

uation model is shown in detail in Figure 2.

Figure 2: Methodology.

The top of the ﬁgure shows the two core compo-

nents of server-based signature solutions according to

the generic architecture introduced in Section 3: the

System under Evaluation (SuE) and the Environment.

Both components protect a set of Assets. Assets are

values that need to be protected, e.g. secret crypto-

graphic keys. Assets are exposed to Threats, which

potentially compromise the assets’ security. The set

of potential threats is delimited by a set of Assump-

tions on the environment, in which the SuE is oper-

ated. Furthermore, potential threats are delimited by

a set of Policies. From the made assumptions, de-

ﬁned policies, and identiﬁed threats, a set of Security

Objectives is derived. The derived security objectives

counter all identiﬁed threats and are also suitable to

meet all made assumptions and deﬁned policies.

According to this methodology, the proposed eval-

uation model for server-based signature solutions has

been developed as follows. Based on the generic ar-

chitecture shown in Figure 1, we have ﬁrst deﬁned

a set of assets that need to be protected by server-

based signature solutions. From these assets, poten-

tial threats have been identiﬁed that threaten to com-

promise the assets’ security. Identiﬁcation of poten-

tial threats has been based on a set of predeﬁned as-

sumptions on the environment and on a predeﬁned set

of policies. Assumptions, policies, and threats have

then been used to derive security objectives for server-

based signature solutions.

Concrete implementations of server-based signa-

ture solutions can be assessed with the proposed eval-

uation model by verifying if the given implementation

meets all security objectives and is hence protected

against all possible threats. Thus, the developed eval-

uation model is roughly comparable with a Protection

Proﬁle according to Common Criteria, whereas the

identiﬁed security objectives of our model correspond

to security requirements of typical Protection Proﬁles.

5 EVALUATION MODEL

In this section, we develop an evaluation model

for server-based signature solutions following the

methodology introduced in Section 4. To facilitate an

understanding of analogies and relevant differences

between the Protection Proﬁle we rely on and the

proposed evaluation model, we intentionally re-use

notations that have been deﬁned and introduced in

(CEN/ISSS, 2001). In the following subsections, we

develop the proposed evaluation model stepwise by

following the methodology described above.

5.1 Assets

Assets deﬁne values that need to be protected. From

the implementation-independent architectural model

deﬁned in Section 3, the following assets can be de-

rived for server-based signature solutions:

A.1 SCD: SCD (signature-creation data) are private

cryptographic keys, which are uniquely assigned

to the Signatory (i.e. the user). These keys are

used by the Signatory to create electronic signa-

tures. SCD must always be kept conﬁdential and

protected from unauthorized access.

A.2 SVD: SVD (signature-veriﬁcation data) are public

keys, which are required to verify signatures cre-

ated with the corresponding SCD. The integrity of

SVD must be preserved.

A.3 DTBS and DTBS display: DTBS (data to be

signed) represent the input to a signature-creation

process, i.e. the data being signed by applying a

cryptographic signature-creation function. The in-

tegrity of these data must be preserved before and

during the signing process as well as during dis-

playing these data to the Signatory in the course

of the signature-creation process for conﬁrmation

purposes.

A.4 VAD: VAD (veriﬁcation authentication data) need

to be provided by the Signatory to authorize a

signature-creation process. According to the used

architectural model, VAD are represented by secret

passwords. The authenticity and conﬁdentiality of

these data must be preserved.

AnImplementation-independentEvaluationModelforServer-basedSignatureSolutions

305

A.5 Signature-creation Function: The cryptographic

method used to create electronic signatures must

comply with approved quality standards.

A.6 Electronic Signature: Created electronic signa-

tures must be tamper-proof.

A.7 OTP: The conﬁdentiality and integrity of one-time

passwords (OTP) that are used by the Signatory to-

gether with her VAD must be preserved.

A.8 User Data: The integrity and conﬁdentiality

of Signatory-related data stored in the central

database must be preserved.

A.9 User ID: The user ID unambiguously identiﬁes

the Signatory. This is necessary to select the cor-

rect SCD for each signature-creation process and to

send the OTP to the correct user. The conﬁdential-

ity and integrity of the user ID must be preserved.

A.10 Database: The database stores all required user-

related data. The integrity of the database must be

preserved and access to the database must be pro-

tected.

A.11 Signature server: The signature server provides

functionality for accessing internal server compo-

nents such as the database or the HSM. Physical

and electronic access to the signature server must

be protected and its integrity must be preserved.

A.12 HSM: The HSM (hardware security module) pro-

vides cryptographic functionality on a secure and

reliable basis. Physical and electronic access to the

HSM must be protected and its integrity must be

preserved.

A.13 HSM Master Key: This is a secret key that is unique

for each HSM, and which is used to protect the

HSM’s functionality and data. This key must al-

ways be kept conﬁdential.

A.14 Session ID: The session ID is used to uniquely map

a signature-creation operation to a speciﬁc Signa-

tory and facilitates the parallel processing of re-

quests from multiple Signatories. The integrity of

the session ID must be preserved.

5.2 Assumptions

The following assumptions deﬁne properties and ca-

pabilities of the environment, in which the SuE is op-

erated. The made assumptions delimit the set of po-

tential threats for identiﬁed assets. All assumptions

must be covered by appropriate security objectives.

AS.1 CGA Cert: The Signature Server and the CA (cer-

tiﬁcate authority) are able to mutually authenticate

each other.

AS.2 CGA Init: The CA implements an appropriate reg-

istration and identiﬁcation procedure and transmits

relevant information to the Signature Server.

AS.3 CGA Secure: The Signature Server has a secure

channel to the CA, which is able to issue appro-

priate signing certiﬁcates according to given legal

requirements and to verify that the user has access

to her private keys.

AS.4 OTP Trusted: The OTP Gateway is trusted and can

be authenticated by the Signature Server.

AS.5 OTP Secure: OTPs can be transmitted from the

Signature Server to the OTP Gateway through a se-

cure channel.

AS.6 User Trusted: The Signatory uses a trustworthy

end-user system to access signature-creation func-

tionality provided by the Signature Server and to

receive OTPs.

AS.7 User Secure: The user communicates with the Sig-

nature Server through a secure channel.

AS.8 Avail: All external components are available dur-

ing the registration and/or the signature-creation

process.

5.3 Policies

Similar to assumptions on the environment, the deﬁ-

nition of policies helps to delimit the set of potential

threats. Again, all deﬁned policies must be covered

by appropriate security objectives. For the proposed

evaluation model, the following policies have been

deﬁned:

P.1 CA QCert: The CA is able to issue certiﬁcates for the

Signatory’s public key (SVD) according to the require-

ments deﬁned by the relevant legal framework.

P.2 QSign: The Signatory uses an electronic-signature

scheme that complies with given legal frameworks and

requirements.

P.3 Sig System: The Signatory’s private key (SCD) is vir-

tually unique.

P.4 HSM Secure: The HSM is able to securely import and

export data. The HSM does never export its secret mas-

ter key. The HSM features secure cryptographic key

generation and signing functions.

P.5 HSM Sig: Electronic signatures are created inside the

HSM only if all required data are available in the HSM

and if all components of the SuE are in a deﬁned state.

P.6 System Secure: The SuE is deployed and operated in an

appropriately secured environment and its components

are protected from unauthorized access.

5.4 Threats

Based on the architectural model deﬁned in Section

3, several threats can be derived that threaten to com-

promise the security of identiﬁed assets. Considering

the above-deﬁned assumptions and policies, the fol-

lowing threats can be derived:

T.1 Hack

Phys: An attacker accesses physical interfaces of

the SuE to mount physical attacks such as side-channel

analysis or fault attacks.

T.2 SCD Divulg: An attacker gains access to conﬁdential

SCD stored by the SuE.

T.3 SCD Derive: An attacker derives conﬁdential SCD

from public data such as SVD or electronic signatures

created with the SCD.

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

306

Table 1: Assets targeted by threats.

A.1

A.2

A.3

A.4

A.5

A.6

A.7

A.8

A.9

A.10

A.11

A.12

A.13

A.14

T.1 X X X X X

T.2 X X X

T.3 X X X

T.4 X X

T.5 X X

T.6 X

T.7 X X

T.8 X

T.9 X X X

T.10 X X

T.11 X X X X

T.12 X

T.13 X

T.14 X X X X

T.15 X X X X X X X X X X X

T.16 X X X X

T.17 X X X X X

T.18 X

T.19 X X X X X

T.20 X X X X X

T.21 X X X X X X X X

T.4 Sig Forgery: An attacker forges signed data or the cor-

responding electronic signature.

T.5 Sig Repud: An attacker compromises the non-

repudiation of an electronic signature by modifying

signature-relevant data.

T.6 SVD Forgery: An attacker forges the Signatory’s pub-

lic key (SVD) during transmission to the CA in order to

compromise the SVD’s integrity.

T.7 DTBS Forgery: An attacker modiﬁes the DTBS that

are displayed to the user. This way, the Signatory can

be tricked into signing unintended data.

T.8 SigF Misuse: An attacker misuses functionality pro-

vided by the system to sign arbitrary data on behalf of

the legitimate Signatory without her knowledge.

T.9 OTP Forgery: An attacker modiﬁes or blocks delivered

OTPs. This way, successful user authentication and

hence signature-creation processes can be prevented by

the attacker.

T.10 OTP Replay: An attacker uses an intercepted OTP to

authorize subsequent signature-creation processes.

T.11OTP Derive: An attacker uses an intercepted OTP to

derive useful information such as subsequent OTPs.

T.12 UserID Forgery: An attacker modiﬁes or deletes the

unique ID of a Signatory to redirect the delivery of

authentication data or to prevent successful signature-

creation processes.

T.13 Userdata Forgery: An attacker copies, modiﬁes,

deletes, or publishes user-related data to compromise

their conﬁdentiality.

T.14 DB Forgery: An attacker steals or destroys the in-

ternal database of the SuE to compromise the system’s

integrity.

T.15 Server Forgery: An attacker steals or destroys the

Signature Server to compromise the system’s integrity.

T.16 HSM Forgery: An attacker steals or destroys the HSM

of the SuE to compromise the system’s integrity and to

reveal conﬁdential data.

T.17 HSM Compr: An attacker compromises the master

key of the HSM to gain access to assets stored inside

the HSM.

T.18 PIN Compr: An attacker gains access to the Signa-

tory’s VAD. This partly compromises the authentication

scheme, which protects the Signatory’s centrally stored

private keys.

T.19 Sess Forgery: An attacker guesses, modiﬁes, or cre-

ates the ID of a session between the Signatory and the

SuE. This enables an attacker to terminate an estab-

lished session or to impersonate the Signatory.

T.20 Sess Hijack: An attacker hijacks an established ses-

sion between the Signatory and the SuE to gain the

same privileges as the legitimate Signatory.

T.21 System Malfunc: A malfunction of one or more

components of the system leads to errors during the

signature-creation process.

Each identiﬁed threat potentially applies to one or

multiple assets. The concrete mapping between as-

sets deﬁned in Section 5.1 and threats deﬁned in this

section is provided in Table 1.

5.5 Security Objectives

A secure and reliable server-based signature solution

must be able to counter all potential threats and meet

all made assumptions and deﬁned policies. From

the identiﬁed threats, made assumptions, and deﬁned

policies listed above, we can therefore derive the fol-

lowing set of security objectives:

O.1 Lifecycle Security: The SuE must be able to detect

errors during initialization, personalization, and oper-

ation.

O.2 SCD Secrecy: The conﬁdentiality of the Signatory’s

private key (SCD) must be guaranteed.

O.3 SCD SVD Corresp: The SuE assures the correct re-

lation between the Signatory’s private and public key.

Upon request, the SuE must be able to verify the rela-

tion between private and public key.

O.4 SVD Auth: The SuE provides means that enable the

CA to verify the authenticity of the Signatory’s public

key (SVD).

O.5 Tamper ID: The SuE is able to detect physical manip-

ulations of its components.

O.6 Tamper Resistance: The SuE is resistant against ma-

nipulations of its components.

O.7 Tamper Response: The SuE performs appropriate ac-

tions to protect components or data when tampering of

the SuE has been detected.

O.8 Init: The SuE provides appropriate means to assure

that private and public keys can be created by autho-

rized persons only.

O.9 SCD Unique: The SuE guarantees an appropriate level

of quality for cryptographic keys. Private keys (SCD)

must be virtually unique and must not be derivable from

corresponding public keys (SVD).

AnImplementation-independentEvaluationModelforServer-basedSignatureSolutions

307

Table 2: Threats, assumptions, and policies covered by security objectives.

Threats/Assumptions/Policies vs. Objectives

O.1 Lifecycle Security

O.2 SCD Secrecy

O.3 SCD SVD Corresp

O.4 SVD Auth

O.5 Tamper ID

O.6 Tamper Resistance

O.7 Tamper Response

O.8 Init

O.9 SCD Unique

O.10 DTBS Integrity

O.11 Sig SigF

O.12 Sig Secure

O.13 HSM Secure

O.14 HSM Trusted

O.15 HSM Feature

O.16 HSM Sig

O.17 Server Trusted

O.18 System Secure

O.19 VAD Secure

O.20 DB Access

O.21 DB Secure

O.22 DB Encrypt

O.23 DB Bound

O.24 System Avail

O.25 CA QCert

O.26 SVD Auth CA

O.27 CA Auth

O.28 VAD Auth

O.29 VAD Secure

O.30 User Trusted

O.31 User Secure

O.32 Avail

T.1 Hack Phys X X X X

T.2 SCD Divulg X X X X X X X

T.3 SCD Derive X X X

T.4 Sig Forgery X X X X X X X X X X X X

T.5 Sig Repud X X X X X X X X X X X X X X X X X X X

T.6 SVD Forgery X X

T.7 DTBS Forgery X X X X X X

T.8 SigF Misuse X X X X X X X X X

T.9 OTP Forgery X X X X X

T.10 OTP Replay X X X X X X

T.11 OTP Derive X X

T.12 UserID Forgery X X X X

T.13 Userdata Forgery X X X X

T.14 DB Forgery X X X

T.15 Server Forgery X X X

T.16 HSM Forgery X X X

T.17 HSM Compr X

T.18 PIN Compr X X X X

T.19 Sess Forgery X X X X

T.20 Sess Hijack X X

T.21 System Malfunc X X

AS.1 CGA Cert X

AS.2 CGA Init X

AS.3 CGA Secure X

AS.4 OTP Trusted X

AS.5 OTP Secure X

AS.6 User Trusted X

AS.7 User Secure X

AS.8 Avail X

P.1 CA QCert X X

P.2 QSign X X X

P.3 Sig System X X X

P.4 HSM Secure X X X X X

P.5 HSM Sig X X

P.6 System Secure X

O.10 DTBS Integrity: The SuE must assure that DTBS

are not modiﬁed while transmitted to the HSM. Fur-

thermore, DTBS must not be modiﬁed when being dis-

played to the Signatory. The SuE must assure that ex-

actly the same DTBS are displayed and signed by the

HSM.

O.11 Sig

SigF: The SuE provides signature-creation func-

tionality to legitimate users only and protects a Signa-

tory’s private key from access and use by others.

O.12 Sig Secure: The SuE creates electronic signatures,

which cannot be forged without knowledge of the pri-

vate key (SCD). The private key cannot be derived from

created signatures.

O.13 HSM Secure: The HSM provides appropriate means

to securely transmit security-critical data such as SCD

or DTBS.

O.14 HSM Trusted: The trustworthiness of the HSM and

its cryptographic operations must be guaranteed.

O.15 HSM Feature: The HSM must be designed and im-

plemented such that an error-free and correct operation

is assured.

O.16 HSM Sig: The HSM is able to carry out all required

cryptographic operations in a protected environment.

O.17 Server Trusted: The signature-server component

must be implemented according to its speciﬁcation and

must process signature-creation requests as expected.

O.18 System Secure: It must be assured that the SuE and

all of its components are protected against physical

and electronic intrusion and that signature-creation pro-

cesses are carried out correctly.

O.19 VAD Secure: Authentication data (VAD) that are

used to authenticate Signatories prior to signature-

creation processes must be protected against misuse by

unauthorized persons.

O.20 DB Access: Access to the SuE’s database must be

restricted to authorized persons and components.

O.21 DB Secure: Data transmissions to the database from

other components must rely on secure communication

channels to prevent eavesdropping and modiﬁcation of

transmitted data.

O.22 DB Encrypt: The SuE must assure that user-related

data stored in the database can be accessed by the cor-

rect user and can be used for signature-creation pro-

cesses of this user only.

O.23 DB Bound: Private keys (SCD) must be bound to the

HSM. Furthermore, the use of private keys must be lim-

ited to the signing of DTBS.

O.24 System Avail: Technical and organizational means

must be in place to assure the availability of the SuE

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

308

and to guarantee that no data are lost in case of system

errors or crashes.

O.25 CA QCert: The CA creates certiﬁcates according to

the given legal requirements.

O.26 SVD Auth CA: The CA veriﬁes the integrity of the

obtained public key (SVD), checks the origin of the

public key, and veriﬁes the relation between public key

and private key.

O.27 CA Auth: The CA must authenticate at the SuE.

Furthermore, the SuE and the CA must communicate

over an authenticated and secure channel.

O.28 VAD Auth: The OTP Gateway must be able to prove

its trustworthiness.

O.29 VAD Secure: The SuE and the OTP Gateway must

communicate over an authenticated and secure channel.

O.30 User Trusted: The Signatory must assure that the

used end-user system is trustworthy and free from mal-

ware and other sources of interference.

O.31 User Secure: The Signatory must assure that her

communication with the SuE relies on a secure and

trustworthy channel.

O.32 Avail: Technical and organizational means must be in

place to assure the availability of external components.

By meeting the derived security objectives, which

ﬁnally represents the developed evaluation model,

server-based signature solutions are able to counter all

identiﬁed threats and meet all made assumptions and

deﬁned policies. Each security objective covers one

or multiple threats, assumptions, or policies. The con-

crete mapping between security objectives, threats,

assumptions, and policies is provided in Table 2.

6 CONCLUSIONS

In this paper we have proposed an evaluation model

for the systematic assessment of arbitrary server-

based signature solutions. The proposed model ba-

sically deﬁnes a set of implementation-independent

security objectives. Security objectives have been

derived following an elaborate methodology aligned

upon the approved concept of Common Criteria. The

security of a concrete server-based signature solution

can be assessed with the help of the proposed evalu-

ation model by determining its capability to meet the

set of deﬁned security objectives.

Application of the proposed evaluation model to

existing server-based signature solutions is regarded

as future work and will kill two birds with one stone.

First, the soundness of the proposed evaluation model

will be evaluated. Second, existing server-based sig-

nature solutions will be systematically assessed in

order to identify potential security vulnerabilities.

By providing a universal evaluation model for arbi-

trary implementations, the proposed evaluation model

helps to assess and assure the security of future server-

based signature solutions. This facilitates a future

adoption of server-based signature solutions also in

security-critical ﬁelds of application and paves the

way for secure and usable online services based on

electronic signatures.

REFERENCES

A-Trust (2010). Activate mobile phone signature.

http://www.buergerkarte.at/en/activate-mobile.html.

Bicakci, K. and Baykal, N. (2003). Saots: A new efﬁcient

server assisted signature scheme for pervasive com-

puting. In Hutter, D., Mller, G., Stephan, W., and

Ullmann, M., editors, SPC, volume 2802 of Lecture

Notes in Computer Science, pages 187–200. Springer.

Bicakci, K. and Baykal, N. (2005). Improved server assisted

signatures. Computer Networks, 47(3):351–366.

CEN/ISSS (2001). Protection proﬁle - se-

cure signature creation device type 3.

http://wwww.commoncriteriaportal.org/ﬁles/pp

ﬁles/pp0006b.pdf.

Common Criteria (2013). Common criteria.

http://www.commoncriteriaportal.org/.

Ding, X., Mazzocchi, D., and Tsudik, G. (2002). Experi-

menting with server-aided signatures. In NDSS. The

Internet Society.

European Committee for Standardization (2013). Se-

curity requirements for trustworthy systems

supporting server signing. https://shop.austrian-

standards.at/Preview.action?preview=&dokkey=478405.

European Council (2004). Multidisciplinary ad hoc group

of specialists on legal, operational and technical stan-

dards for e-enabled voting (ip1-s-ee) b. explanat.

European Union (1999). Directive 1999/93/ec of the eu-

ropean parliament and of the council of 13 december

1999 on a community framework for electronic signa-

tures.

European Union (2012). Proposal for a regulation of the

european parliament and of the council on electronic

identiﬁcation and trust services for electronic transac-

tions in the internal market.

Forum of European Supervisory Authorities for Electronic

Signatures (2005). Public statement on server based

signature services. http://www.fesa.eu/public-

documents/PublicStatement-

ServerBasedSignatureServices-20051027.pdf.

Orthacker, C., Centner, M., and Kittl, C. (2010). Qualiﬁed

mobile server signature. In Proceedings of the 25th

TC 11 International Information Security Conference.

Zefferer, T. and Krnjic, V. (2012). Usability evaluation

of electronic signature based e-government solutions.

In Proceedings of the IADIS International Conference

WWW/INTERNET 2012, pages 227 – 234.

AnImplementation-independentEvaluationModelforServer-basedSignatureSolutions

309