Towards a Modular Architecture for Adaptable Signature-veriﬁcation

Tools

Thomas Lenz, Klaus Stranacher and Thomas Zefferer

Secure Information Technology Center - Austria, Inffeldgasse 16a, Graz, Austria

Keywords:

Electronic Signatures, Veriﬁcation, Testing, Web Services.

Abstract:

The veriﬁcation of electronic signatures represents a key component of security-sensitive applications.

Signature-veriﬁcation tools need to meet several requirements regarding security, reliability, usability, and

accessibility. A conducted survey revealed that existing signature-veriﬁcation tools often meet only a subset

of these requirements. In most cases, available tools support a limited set of document and signature formats

only, or do not feature appropriate interfaces that allow both end users and third-party applications to access

the tool’s functionality in a convenient way. This complicates the development of electronic signature based

third-party applications and reduces the usability for end users. To solve this problem, we propose a new archi-

tecture for Web based signature-veriﬁcation tools. The proposed architecture follows a plug-in based approach

that eases the integration of new signature formats and interfaces. The practical applicability of the proposed

architecture is demonstrated by means of a concrete implementation covering different use cases. This im-

plementation demonstrates that the proposed architecture facilitates the realization of signature-veriﬁcation

tools that are able to meet all requirements of end users and third-party applications. This way, the proposed

architecture and the implemented solution contribute to the security, usability, and efﬁciency of present and

future electronic signature based applications.

1 INTRODUCTION

Electronic signatures are an integral component of

various solutions related to security sensitive ﬁelds of

application. Such solutions typically have strict re-

quirements regarding data integrity, authenticity, and

non-repudiation of origin. Electronic signatures are

perfectly suitable to meet these requirements. The

importance of electronic signatures has also been rec-

ognized by legislative bodies. For instance, the Eu-

ropean Union has harmonized the use of electronic

signatures in EU Member States through the Direc-

tive 1999/93/EC of the European Parliament and of

the Council of 13 December 1999 on a Community

framework for electronic signatures (The European

Parliament and the Council of the European Union,

2000), henceforth referred to as EU Signature Direc-

tive. The EU Signature Directive distinguishes be-

tween advanced and qualiﬁed electronic signatures.

Compared to advanced electronic signatures, quali-

ﬁed electronic signatures have to fulﬁll several ad-

ditional security requirements

and are deﬁned to be

These requirements basically cover the use of secure

signature-creation devices (e.g. smart cards or similar se-

legally equivalent to handwritten signatures.

The legal equivalence to handwritten signatures

makes qualiﬁed electronic signatures especially use-

ful for the realization of e-government solutions pro-

vided by the public sector. Numerous countries are

already issuing e-ID and e-signature tokens to their

citizens. Citizens can use these tokens to remotely au-

thenticate at e-government portals, to carry out elec-

tronic procedures, and to electronically sign docu-

ments. Smart card based e-ID and e-signature tokens

have for instance been issued to citizens in Austria

Belgium

, Estonia

, Germany

, Portugal

, or Spain

A few countries such as Austria

and Estonia

addi-

tionally allow citizens to use their mobile phones as

cure elements) and reliance on qualiﬁed electronic signa-

tures.

https://www.buergerkarte.at/

http://eid.belgium.be/en/

http://www.id.ee/

http://www.personalausweisportal.de

http://www.cartaodecidadao.pt/

http://www.dnielectronico.es/

https://www.handy-signatur.at/Default.aspx

http://e-estonia.com/components/mobile-id

325

Lenz T., Stranacher K. and Zefferer T..

Towards a Modular Architecture for Adaptable Signature-veriﬁcation Tools.

DOI: 10.5220/0004356303250334

In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST-2013), pages 325-334

ISBN: 978-989-8565-54-9

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

e-ID and e-signature tokens. In numerous countries,

also service providers from the private sector rely on

e-ID and e-signature tokens issued by the public sec-

tor. For instance, several e-banking portals support a

secure user authentication based on available e-ID and

e-signature tokens and allow users to authorize ﬁnan-

cial transactions remotely using electronic signatures.

Additionally, electronic signatures are also frequently

used in the private domain, e.g. to sign electronic con-

tracts or similar bilateral agreements. Required sig-

nature tokens and signing certiﬁcates can usually be

acquired from national certiﬁcation authorities. Due

to their various ﬁelds of application in both the pub-

lic and the private domain, electronic signatures are

increasingly gaining importance all over the world.

A key advantage of electronic signatures com-

pared to handwritten signatures is their veriﬁability.

Given a handwritten signature, its authenticity and

originality is difﬁcult to determine in practice. Ad-

ditionally, subsequent modiﬁcations that have been

applied to e.g. a signed contract might be difﬁcult

to detect in case of handwritten signatures. This is

not the case for electronic signatures. The validity,

authenticity, and originality of electronic signatures

can be unambiguously determined by means of cryp-

tographic operations that are based on strong mathe-

matical foundations. Each electronic signature is un-

ambiguously linked to the identity of a certain per-

son by means of an electronic certiﬁcate that has been

issued by a trusted third party, i.e. a certiﬁcation au-

thority. Additionally, each subsequent modiﬁcation of

a signed document immediately invalidates the elec-

tronic signature. Thus, by verifying its electronic sig-

nature, integrity, authenticity, and non-repudiation of

origin of signed data can be reliably assessed.

In practice, the veriﬁcation of electronic signa-

tures is actually no trivial task as it requires the ap-

plication of complex cryptographic methods. Hence,

there is a need for appropriate tools that implement

this functionality. Tools and Web based services that

allow for a convenient veriﬁcation of electronic signa-

tures have already been deployed in several countries.

Austria is a representative example, since this coun-

try has started to rely on electronic signature based

solutions early (Leitold H., 2002). Austrian citizens

are provided with a Web based veriﬁcation tool that

can be used to upload and verify electronically signed

documents (Zefferer et al., 2011). This tool supports

various document and signature formats and is there-

fore able to act as single point of contact for the veri-

ﬁcation of arbitrary electronic signatures.

Unfortunately, the Austrian signature-veriﬁcation

tool is optimized for manual use by citizens, i.e. the

only opportunity to interact with this tool is by man-

ually uploading signed documents. This signiﬁcantly

aggravates an automated use of this tool, e.g. the inte-

gration of the tool’s functionality into third-party ap-

plications, which for instance need to implement an

on-the-ﬂy veriﬁcation of electronically signed docu-

ments. To overcome this issue, we present an im-

proved signature-veriﬁcation tool that enhances the

existing solution by extended interfaces and commu-

nication capabilities. This way, approved compo-

nents and key functionality of the existing solution are

maintained, while access to the tool’s functionality is

facilitated.

The remainder of this paper is structured as fol-

lows. In Section 2, general requirements of signature-

veriﬁcation solutions are deﬁned. In Section 3, we

show that existing signature-veriﬁcation solutions are

often not able to meet all of these requirements. In

Section 4, we present an enhanced architecture of the

approved Austrian signature-veriﬁcation tool that im-

proves its functionality and accessibility. We demon-

strate the practical applicability of our approach by

presenting a concrete implementation that is based on

the proposed architecture in Section 5. Finally, con-

clusions are drawn in Section 6.

2 REQUIREMENTS

The secure and reliable veriﬁcation of electronic sig-

natures represents a key component of electronic sig-

nature based applications and services. Signature-

veriﬁcation tools must meet various requirements

in order to satisfy the needs of users and service

providers. Requirements that need to be met by

signature-veriﬁcation tools have been identiﬁed and

discussed in detail in (Zefferer et al., 2011). How-

ever, these requirements mainly focus on the end-user

perspective and do not cover aspects that are speciﬁc

to providers of electronic signature based applications

and services. Considering the needs of both users and

service providers, the following key requirements for

signature-veriﬁcation tools can be derived.

• Security. Electronic signatures are typically used

in security-sensitive applications. If signature-

veriﬁcation tools process security-sensitive data,

these data need to be protected appropriately in

order to assure their conﬁdentiality. Furthermore,

signature-veriﬁcation tools need to be resistant

against attacks that threaten to illegally inﬂuence

results of signature-veriﬁcation processes.

• Reliability. End users and service providers that

make use of signature-veriﬁcation tools must be

able to rely on the results of signature-veriﬁcation

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

326

processes. Thus, signature-veriﬁcation tools must

be able to correctly distinguish between valid and

invalid electronic signatures at any time. Given

the legal equivalence of qualiﬁed electronic signa-

tures to handwritten signatures, the correctness of

presented veriﬁcation results is of particular im-

portance.

• Usability. The requirement for usability covers

several aspects such as simplicity of veriﬁcation

processes from the user point of view, hiding of

complexity, platform independence, or avoidance

of local software installations. An important as-

pect for both end users and service providers that

make use of signature-veriﬁcation tools is the re-

quirement for a single point of contact. Signature-

veriﬁcation tools need to provide users and ser-

vice providers a single interface, through which

arbitrary document and signature formats can be

veriﬁed.

• Accessibility. The functionality provided by

signature-veriﬁcation tools must be easily acces-

sible for both end users and providers of third-

party applications. To meet this requirement for

end users, the provided user interface needs to

comply with established usability and accessibil-

ity standards such as the Web Content Accessibil-

ity Guidelines (WCAG) (World Wide Web Con-

sortium, 2008a). In order to meet the accessibility

requirement for providers of third-party applica-

tions, signature-veriﬁcation tools need to imple-

ment appropriate interfaces that can be accessed

by external applications to carry out signature-

veriﬁcation processes.

The above deﬁned requirements are rather generic

and not bound to a speciﬁc legal framework. De-

pending on the legal and organizational environment,

in which a signature-veriﬁcation tool is deployed,

several additional requirements might apply. For

instance, in the special case of Austria, signature-

veriﬁcation tools have to support proprietary signa-

ture formats that are frequently used in Austrian e-

government solutions. Different legal requirements

of different countries have already led to the devel-

opment of numerous signature-veriﬁcation tools. In

the next section, available signature-veriﬁcation tools

are surveyed and their capabilities to meet the above

deﬁned requirements are assessed.

3 EXISTING SOLUTIONS

The growing importance of electronic signature based

solutions and the plurality of legal requirements

have led to the development of different signature-

veriﬁcation solutions. Depending on the context of

the deployment, these solutions usually meet a subset

of the requirements deﬁned in Section 2.

For instance, Unizeto Technologies SA

provides

a publicly available Web based signature veriﬁca-

tion tool called WebNotarius

. Having its roots

in Poland, WebNotarius supports the veriﬁcation of

public-key certiﬁcates issued by certiﬁed Polish cer-

tiﬁcation authorities. Additionally, WebNotarius sup-

ports the veriﬁcation of different document and sig-

nature formats including PKCS#7 (RSA Laborato-

ries, 1993), CMS (Housley, 2009), S/MIME (Rams-

dell and Turner, 2010), and XMLDSig (World Wide

Web Consortium, 2008b).

A similar Web based signature-veriﬁcation tool is

provided by the German company signagate

. Com-

pared to WebNotarius, signagate is restricted to the

PDF ﬁle format (Adobe Corporation, 2008) and does

not support different document and signature formats.

Another Web based veriﬁcation tool for electroni-

cally signed PDF documents is provided by the com-

pany Secured Signing

. The company ascertia

of-

fers Web based tools for the veriﬁcation of electron-

ically signed PDF and XML ﬁles. A solution for the

veriﬁcation of XML signatures called MOA-SP

also provided by the Austrian government to facili-

tate the integration of XML signatures into Austrian

e-government applications. MOA-SP is available as

open source and features API and Web service based

interfaces for the veriﬁcation of electronically signed

XML documents, namely XMLDSig (World Wide

Web Consortium, 2008b) and XAdES (ETSI TS 101

903, 2010).

There exist also several signature-veriﬁcation ac-

tivities at a European level. The tool SD-DSS

, com-

missioned by the EU Commission, supports the ver-

iﬁcation of signature formats deﬁned by the Com-

mission Decision on establishing minimum require-

ments for the cross-border processing of documents

(European Commission, 2011). Additionally, the EU

large scale pilots PEPPOL

and SPOCS

addressed

issues concerning the validation of electronic sig-

natures. PEPPOL developed a signature validation

http://www.unizeto.pl/

http://www.webnotarius.eu

http://www.signagate.de/

http://www.securedsigning.com/

http://www.ascertia.com/

https://joinup.ec.europa.eu/software/moa-idspss/

description

https://joinup.ec.europa.eu/software/sd-dss/home

http://www.project.peppol.eu/

http://www.eu-spocs.eu/

TowardsaModularArchitectureforAdaptableSignature-verificationTools

327

service with focus on public procurement processes.

Within SPOCS, signature veriﬁcation is part of the

validation of electronic documents concerning the is-

sues raised by the EU Services Directive (The Eu-

ropean Parliament and the Council of the European

Union, 2006).

All above mentioned solutions show very well the

key problem of current signature-veriﬁcation solu-

tions. Most solutions are limited to the veriﬁcation of

certain document and signature formats such as XML

or PDF. Hence, these solutions do not satisfy the us-

ability requirement for a single point of contact for

the veriﬁcation of all document and signature formats.

Even the tool WebNotarius, which supports several

different formats, only covers a subset of all possible

document and signature formats. This is actually not

surprising, as proprietary signature formats exist in

several countries due to national legal requirements.

For instance, in Austria a proprietary PDF signature

format (Leitold et al., 2009) has been introduced for

the public sector in order to meet speciﬁc legal re-

quirements (Leitold et al., 2010). Support for all na-

tional and international, standardized and proprietary

signature formats rapidly increases the complexity of

signature-veriﬁcation tools.

This situation is even aggravated by the fact that

especially proprietary signature formats are subject to

frequent revisions and updates. As electronic signa-

tures need to retain their validity even if the underly-

ing signature format is updated, signature-veriﬁcation

tools have to maintain and support different versions

of signature formats. This again increases the com-

plexity of such tools and renders their development

and maintenance difﬁcult. As a ﬁrst solution to this

problem, Stranacher and Kawecki have proposed a

mechanism to incorporate external veriﬁcation ser-

vices (Stranacher and Kawecki, 2012). However, this

proposal lacks on an appropriate and efﬁcient docu-

ment and signature format detection.

In order to cope with the growing diversity of dif-

ferent document and signature formats, a Web based

signature-veriﬁcation tool has been developed in Aus-

tria. This tool features a modular design and imple-

ments an efﬁcient format detection engine that eases

the integration of new document and signature for-

mats. The signature-veriﬁcation tool that has been

discussed in detail in (Zefferer et al., 2011) has basi-

cally proven its practical applicability during several

years of productive operation. Still, this tool suffers

from several limitations. For instance, the tool is in-

dented for manual use only. Users can upload doc-

uments to be veriﬁed through a Web based user in-

terface. As this is the only supported interface, the

tool’s functionality cannot be easily accessed by ex-

ternal applications to carry out signature veriﬁcations.

Furthermore, the given limitation to a Web based in-

terface complicates the provision of the tool’s func-

tionality through new communication channels and

emerging technologies such as mobile apps. Thus,

this tool is obviously not able to meet accessibility

requirements for service providers and third-party ap-

plications.

In summary it can be stated that there is currently

no perfect solution available. From the Austrian per-

spective, powerful tools such as WebNotarius that

have been developed in other countries are no alter-

native, as these solutions do not support proprietary

document and signature formats that are speciﬁc to

Austria. Hence, these solutions do not meet the pre-

deﬁned requirement for provision of a single point of

contact for the veriﬁcation of all document and sig-

nature formats. Unfortunately, the existing Austrian

solution that supports these proprietary document and

signature formats does not feature appropriate inter-

faces to meet the predeﬁned requirement for acces-

sibility. Hence, third-party applications are not able

to access the functionality provided by the available

tool in order to implement fully automated signature-

veriﬁcation processes of electronically signed docu-

ments.

To overcome this problem, we propose an

enhancement of the existing Austrian signature-

veriﬁcation tool. The proposed enhancements im-

prove the accessibility of this tool especially for third-

party applications and facilitate access to the tool’s

functionality. The architectural design of the pro-

posed solution is presented in the next section.

4 ARCHITECTURAL DESIGN

The proposed solution is based on the Austrian Web

based signature-veriﬁcation tool that has been dis-

cussed in the previous section. The Web based ap-

proach followed by this tool has proven to be ad-

vantageous in terms of security and usability during

several years of productive operation (Zefferer et al.,

2011). Figure 1 illustrates the general architecture of

this tool. Key component of the entire solution is the

Process Flow Engine, which coordinates the different

steps of a signature-veriﬁcation process. A signature-

veriﬁcation process basically consists of two steps.

First, the document and signature format of the docu-

ment to be veriﬁed is determined. This task is accom-

plished by the Format Detection Engine. For each

supported format, an appropriate Format Detection

Plug-in has been implemented. Internally, the dif-

ferent Format Detection Plug-ins are organized hier-

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

328

archically in a tree structure. This way, the runtime

for format-detection processes grows only logarithmi-

cally with an increasing number of format-detection

plug-ins. Second, the electronic signature is veriﬁed

by the Veriﬁcation Engine. Depending on the de-

termined document and signature format, an appro-

priate Veriﬁcation Plug-in is selected to accomplish

this task. The selected Veriﬁcation Plug-in extracts

all signatures from the provided document and cryp-

tographically veriﬁes their validity based on the pro-

vided document data.

Proccess Flow

Engine

Format Detection

Engine

Verification Engine

Verification

Plug-in 1

Verification

Plug-in 2

Verification

Plug-in N

PDF XML S/MIME

͘͘͘

Format

Detection

Plug-in 1

Format

Detection

Plug-in 2

Format

Detection

Plug-in N

͘͘͘

PDF XML S/MIME

Web Interface

hƐĞƌ

Figure 1: Architecture of the Austrian Web based signature-

veriﬁcation tool.

Files to be veriﬁed as well as veriﬁcation results

are exchanged with end users by means of a Web In-

terface. Users are provided with a Web form in order

to upload signed documents to be veriﬁed. Results

are directly presented in the users’ Web browsers.

After completion of the signature-veriﬁcation pro-

cess, users can additionally download an electroni-

cally signed version of the veriﬁcation report in PDF

format.

The concept shown in Figure 1 has turned out to

be able to especially meet the expectations and re-

quirements of end users. However, several problems

arise if the functionality of this tool has to be accessed

by third-party applications. As this tool has originally

been developed for end users, its functionality can ba-

sically be accessed through the provided Web based

interface only

. This limitation renders an integra-

tion of the tool’s functionality into third-party appli-

Actually, the tool provides also a command line based

user interface. However, this interface is not appropriate for

an integration of the tool’s functionality into remote third-

party applications either.

cations for automated signature veriﬁcations difﬁcult.

In order to solve this issue and to facilitate an inte-

gration of the tool’s functionality into third-party ap-

plications, we have enhanced the tool’s general archi-

tecture. The resulting extended architecture of our so-

lution is illustrated in Figure 2.

The lack of appropriate interfaces to access the

tool’s functionality through different communication

channels and technologies has turned out to be the

main drawback of the existing solution. Our improved

solution solves this issue by replacing the original

Web interface by a more powerful I/O Engine. This

I/O Engine supports different I/O channels and com-

munication technologies. The I/O Engine adopts the

approved plug-in based approach that is already suc-

cessfully followed by both the Format Detection En-

gine and the Veriﬁcation Engine. This way, the entire

solution remains modular and easily adaptable to fu-

ture requirements.

The adapted architecture and the introduced I/O

Engine facilitate the realization of various additional

use cases. Figure 2 illustrates some of them. Of

course, the approved Web based interface is also com-

patible to the new architecture. A special I/O Plug-in

can implement the required interface. However, the

enhanced architecture is not limited to a Web based

interface any longer. For instance, the proposed ar-

chitecture also allows the tool’s functionality to be

accessed through a SOAP based Web-service inter-

face provided by the tool’s I/O Engine. The modu-

lar design also allows for efﬁcient implementations

of test frameworks that automatically run veriﬁcation

tests on well-deﬁned test documents stored in local

databases. This could be especially useful for the

maintenance and further development of the tool. Fi-

nally, the proposed architecture also allows for the in-

tegration of new and emerging technologies such as

smartphone apps that access the tool for an on-the-ﬂy

veriﬁcation of electronic signatures.

We have evaluated the practical applicability of

the proposed architectural design by realizing three

of the above-mentioned use cases in practice. Details

on the realization of these use cases are provided in

the next section.

5 USE CASES

Core component of the proposed architecture is the

I/O Engine that replaces the original Web based user

interface and allows for the implementation of differ-

ent I/O Plug-ins. These plug-ins implement different

communication technologies and make the signature-

veriﬁcation tool’s functionality accessible through

TowardsaModularArchitectureforAdaptableSignature-verificationTools

329

Proccess Flow

Engine

Format Detection

Engine

Verification Engine

Verification

Plug-in 1

Verification

Plug-in 2

Verification

Plug-in N

PDF XML S/MIME

͘͘͘

Format

Detection

Plug-in 1

Format

Detection

Plug-in 2

Format

Detection

Plug-in N

͘͘͘

PDF XML S/MIME

I/O Engine

I/O

Plug-in 1

I/O

Plug-in 2

I/O

Plug-in N

͘͘͘

I/O

Plug-in 3

Web

Interface

SOAP

Test

Framework

Mobile App

^ŵĂƌƚƉŚŽŶĞ

dĞƐƚĂƚĂ

^ĞƌǀŝĐĞ

WƌŽǀŝĚ Ğƌ

hƐĞƌ

Figure 2: Enhanced architecture of the Austrian Web based signature-veriﬁcation tool.

different communication channels. This way, the pro-

posed tool can be used in different application sce-

narios. We have demonstrated the applicability of our

solution by implementing solutions for three concrete

use cases, which are discussed below in more detail.

5.1 Use Case 1: Web Interface

Use Case 1 covers the scenario, in which an end user

wants to access the tool’s functionality in order to ver-

ify an electronically signed document. This is basi-

cally the scenario, which the predecessor of the pro-

posed tool has been developed for. For this scenario, a

Web based interface has turned out to be the most ap-

propriate solution. Therefore, our implementation of

this use case relies on the approved Web based inter-

face of the original tool. Of course, it was necessary to

redesign the existing API interface in order to connect

the Web based user interface to the new I/O Engine of

our solution. While several internal components have

been redesigned, the user interface itself has not been

changed. This way, existing productive instances of

the tool can easily be upgraded and do not require end

users to deal with new interfaces. Figure 3 illustrates

the implemented Web interface that can be used by

end users to upload and verify signed documents.

5.2 Use Case 2: SOAP

This scenario covers the case, in which a remote

third-party application makes use of the signature-

veriﬁcation tool’s functionality. In order to allow

third-party applications to access our tool through a

well-deﬁned interface, we have implemented another

I/O Plug-in. This plug-in provides a standardized in-

terface, which can be used by remote applications to

carry out automated signature-veriﬁcation process.

This is actually no completely new approach.

There are already different standards that deﬁne ap-

propriate interfaces for remote signature-veriﬁcation

services. Popular examples are the OASIS Digi-

tal Signature Service (OASIS, 2007) and MOA-SP,

which is mainly used in Austrian e-government solu-

tions. However, these standardized interfaces specify

the veriﬁcation of a limited set of electronic signatures

only. Consequently, these services are not suitable for

scenarios, in which different document and signature

formats need to be supported. Our solution speciﬁes

a new signature-veriﬁcation interface, which fulﬁlls

these additional requirements.

The developed I/O Plug-in implements a Web ser-

vice, which uses the SOAP protocol (Gudgin et al.,

2007) to exchange information. Beneath the SOAP

protocol, the Hypertext Transfer Protocol (HTTP)

(Fielding et al., 1999) is used as carrier for the

SOAP message. This is reasonable, because HTTP

is popular, frequently used, and widely supported.

SOAP messages being exchanged over the imple-

mented Web service interface rely on the Extensible

Markup Language (XML) (Bray et al., 2006). To

meet all requirements of this use case, we have de-

ﬁned our own XML schema for document veriﬁca-

tion

. The XML schema, which deﬁnes the structure

We were forced to deﬁne an own schema, since existing

schemata were not able to meet our requirements.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

330

Figure 3: Web front-end of the signature-veriﬁcation tool.

of a signature-veriﬁcation request that is accepted by

the tool’s Web-service interface, is shown in Listing

According to the deﬁned XML schema, a

signature-veriﬁcation request consists of two XML

elements. The Document element is mandatory and

contains the signed ﬁle to be veriﬁed. The second ele-

ment is optional and can be used to identify the signed

ﬁle. When a schema-compliant SOAP request is re-

ceived, a signature-veriﬁcation operation as shown in

Figure 4 is triggered.

Listing 1: VerifyDocumentRequest XML schema.

<xsd:element name=”VerifyDocumentRequest”>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=”Document”

type=”xsd:base64Binary”/>

<xsd:element name=”FileID”

type=”xsd:token”/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

The ﬁrst step of the whole veriﬁcation process

consists of several preprocessing operations, like

XML schema validation and BASE64 decoding. Af-

terwards, the provided document’s format is deter-

mined using the tool’s Format Detection Engine. Sub-

sequently, the document’s electronic signatures are

veriﬁed using the tool’s Signature Veriﬁcation En-

gine.

Results of the format-detection step and the

signature-veriﬁcation step are collected to generate a

veriﬁcation report. Relevant parts of this veriﬁcation

report are shown in Listing 2. The report’s FileInfo

element contains the FileID of the veriﬁed ﬁle, the de-

tected document format, and the computed hash value

of the document. Signature-veriﬁcation results gener-

ated by the Veriﬁcation Engine are embedded in the

report’s SignatureInfo element.

Listing 2: VeriﬁcationReport XML Schema.

<xsd:complexType name=”VeriﬁcationReportType”>

<xsd:sequence>

<xsd:element name=”FileInfo”

type=” tns:FileInfoType ”/>

<xsd:element name=”SignatureInfo”

type=” tns:SignatureInfoType ”/>

</xsd:sequence>

</xsd:complexType>

Listing 3: VerifyDocumentResponse XML Schema.

<xsd:element name=”VerifyDocumentResponse”>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=”VeriﬁcationReport ”

type=” tns:VeriﬁcationReportType ”/>

<xsd:element name=”Signature”

type=” dsig:SignatureType ”/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

Finally, the generated veriﬁcation report is elec-

tronically signed in order to ensure its authenticity

and integrity. The signed report is returned to the

sender of the SOAP based veriﬁcation request. List-

ing 3 shows relevant parts of the XML schema that

speciﬁes the structure of this SOAP response. The re-

sponse consists of two parts, the VeriﬁcationReport

SOAP

Interface

Pre-

processing

Format

Detection

Signature

Verification

Report

Generation

Report

Signing

Figure 4: Web service based document veriﬁcation process.

TowardsaModularArchitectureforAdaptableSignature-verificationTools

331

and a Signature element, which contains the elec-

tronic signature of the veriﬁcation report. This sig-

nature is created according to the XMLDSig standard

using the enveloped-signature scheme.

The implemented SOAP based Web-service inter-

face provides third-party applications a common in-

terface for on-the-ﬂy signature veriﬁcations. Third-

party applications can use this interface to efﬁciently

carry out veriﬁcation operations on different docu-

ment and signature formats. This way, the provided

solution facilitates the implementation of electronic

signature based applications by encapsulating and

providing common functionality.

5.3 Use Case 3: Test Framework

The growing number of document and signature for-

mats rapidly increases the complexity for developers

and providers of the signature-veriﬁcation tool. The

situation is even more complicated by the fact that

veriﬁcation results are not only inﬂuenced by the in-

put document and the implementation of the veriﬁca-

tion tool, but also by the tool’s conﬁguration. For in-

stance, the validity of an electronic signature depends

to a large extent on root and intermediate certiﬁcates

that are conﬁgured in the tool’s trust stores. Hence,

extensive tests are not only required during develop-

ment, but also after deployment. This use case de-

scribes how the tool’s improved architecture is used

to implement a comprehensive test framework that al-

lows both developers and operators to verify the cor-

rect behavior of the tool.

The implemented test framework makes use of the

tool’s I/O Engine and implements an appropriate I/O

Plug-in. Furthermore, the test framework makes use

of a database containing signed test documents and

corresponding expected veriﬁcation results. By feed-

ing the test documents as input into the signature-

veriﬁcation tool and comparing the obtained results

with the stored expected results, the functional in-

tegrity of the tool can be veriﬁed. Figure 5 gives an

I/O

Plug-in 3

Automatic Test

Engine

User

Interface

Report

Engine

API

Interface

Information

Management

Configuration

I/O

Plug-in 1

I/O

Plug-in 2

Web

Interface

SOAP

I/O

Plug-in N

...

Mobile App

Figure 5: Test Framework with sub-modules and intercon-

nections.

overview of the test framework’s general architecture.

The main part of the test framework is the Au-

tomatic Test Engine, which controls the whole auto-

matic veriﬁcation and test process. The Automatic

Test Engine makes use of several additional sub-

modules. These sub-modules implement an User In-

terface, an Information Management module, and a

Report Engine. As interconnection to the signature-

veriﬁcation tool, we make use of the signature-

veriﬁcation tool’s I/O Engine and its plug-in based

architecture.

The Information Management sub-module is used

to manage the signed test documents and the cor-

responding expected results. We use a ﬁle system

based method to manage the different ﬁles depend-

ing on their document type and signature format. The

expected results are stored in XML ﬁles. Listing 4

shows the XML schema, which deﬁnes the internal

structure of these ﬁles.

Each ﬁle element represents the expected veriﬁca-

tion result of a test document by using a set of child

elements. The name element represents the name

of the signed test document. The number of signa-

tures contained in the test documents is represented

by the numberofsignatures element. For each signa-

ture, the expected veriﬁcation result is stored in a sep-

arate signatures element. For comprehensive func-

tionality tests, the test-document database also con-

tains documents without signatures and documents

with incorrect signatures. All incorrect documents are

marked with the executable ﬂag. XML ﬁles with ex-

pected veriﬁcation results are stored in all directories

and subdirectories of the test-document hierarchy.

Listing 4: XML schema of the veriﬁcation result database.

<element name=”path”

type=” string ”/>

<element name=”ﬁle”

type=” tns:ﬁle ”/>

</sequence>

</complexType>

<element name=”name”

type=” string ”/>

<element name=”executable”

type=”boolean”/>

<element name=”numberofsignatures”

type=” string ”/>

<element name=”signatures”

type=” tns:signature ”/>

</sequence>

</complexType>

Besides the Information Management sub-

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

332

module, the Report Engine represents another

important component of the test framework. The

Report Engine implements the entire report func-

tionality. A report basically contains the number

of tested documents and the number of documents,

in which the signature-veriﬁcation result matches

the expected veriﬁcation result. If the veriﬁcation

result of a test document does not match the expected

result, a detailed report is generated. This report

contains a detailed error description and shows,

which part of the signature veriﬁcation has caused

the problem. By default, the report is rendered as

HTML document and presented to the user via the

user interface. Additionally, the Report Engine can

generate an XML based report or a textual report.

Figure 6: Web based user interface of the Test Engine after

Developers and operators of the signature-

veriﬁcation tool can interact with the test framework

by using a Web based User Interface. Figure 6 illus-

trates the user interface after a successful log-in. The

shown list represents the directory hierarchy, in which

the test documents are organized. The user can select

one type of documents (i.e. one directory) from the

test-document database by selecting the correspond-

ing radio button. Afterwards, the test operation can

be started using the Start new Test button. The Auto-

matic Test Engine controls the entire test process and

uses the Information Management sub-module to get

all documents from the selected directory. Every doc-

ument is veriﬁed by the signature-veriﬁcation tool.

Obtained veriﬁcation results are compared with the

expected veriﬁcation results. The result of this com-

parison is stored and processed by the Report Engine.

When all selected documents have been tested, the

generated HTML report is shown in the Web based

user interface. Figure 7 shows an excerpt from a test

result, in which 457 test documents are in use. Ob-

tained test results can be stored or alternatively a new

test run can be started.

Figure 7: Web based user interface of the Test Engine with

test report.

6 CONCLUSIONS

The secure and reliable veriﬁcation of electronic sig-

natures is an integral component of security-sensitive

applications from various ﬁelds of application such as

e-government, e-banking, or e-business. The capabil-

ity to assess the validity of electronic signatures can

be important for both end users and service providers.

In this paper we have presented a new solution for the

veriﬁcation of electronic signatures. The presented

solution features a single point of contact for the ver-

iﬁcation of various document and signature formats

and relies on a modular architecture that facilitates

future extensions of the solution’s functionality. Al-

though the presented solution has been developed to

meet the special requirements of the Austrian legal

framework, its general architectural design and im-

plementation is also applicable in other contexts.

We have demonstrated the practical applicability

and ﬂexibility of the presented architectural design by

TowardsaModularArchitectureforAdaptableSignature-verificationTools

333

implementing solutions for different use cases. These

use cases cover the use of the presented solution by

end users through a Web based user interface, the pro-

vision of the solution’s functionality through a well-

deﬁned SOAP based Web-service interface, and the

realization of a comprehensive test framework that as-

sists is assessing the correct functionality of our solu-

tion. The realization of further use cases such as the

implementation of mobile smartphone apps that make

use of the presented signature-veriﬁcation tool is re-

garded as future work.

Due to its modular architecture, the presented so-

lution is dynamically extensible especially with re-

spect to new document formats and communication

interfaces. This distinguishes the presented solution

from other signature-veriﬁcation tools that are avail-

able on the market. A conducted survey has revealed

that these tools are typically limited to certain docu-

ment and signature formats, or to certain communica-

tion interfaces. The presented solution removes these

limitations and thereby contributes to the security, us-

ability, and efﬁciency of present and future electronic-

signature based applications.

REFERENCES

Adobe Corporation (2008). Document management -

Portable document format Part 1: PDF 1.7.

Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,

Yergeau, F., and Cowan, J. (2006). Extensible Markup

Language (XML) 1.1 (Second Edition). http://

www.w3.org/TR/2006/REC-xml11-20060816/.

ETSI TS 101 903 (2010). Electronic Signatures and Infras-

tructures (ESI); XML Advanced Electronic Signatures

(XAdES) V1.4.2.

European Commission (2011). European Commission

Decision, Establishing minimum requirements for the

cross-border processing of documents signed elec-

tronically by competent authorities under Directive

2006/123/EC of the European Parliament and of the

Council on services in the internal market, notiﬁed

under document C(2011) 1081, 2011/130/EU. http://

eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:

L:2011:053:0066:0072:EN:PDF.

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,

L., Leach, P., and Berners-Lee, T. (1999). Hypertext

transfer protocol – http/1.1. http://www.ietf.org/ rfc/

rfc2616.txt.

Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J.-J.,

and Nielsen, H. F. (2007). Soap version 1.2 part

1: Messaging framework. http://www.w3.org/TR/

soap12-part1/.

Housley, R. (2009). Cryptographic Message Syntax (CMS).

http://www.ietf.org/rfc/rfc5652.txt.

Leitold, H., Posch, R., and R

ossler, T. (2009). Media-

break resistant eSignatures in eGovernment-An Aus-

trian experience. In Dimitris Gritzalis, J. L., editor,

Emerging Challenges for Security, Privacy, and Trust

- 24th IFIP SEC, volume IFIP AICT 297 of IFIP Ad-

vances in Information and Communication Technolo-

gies, pages 109 – 118. Springer.

Leitold, H., Posch, R., and R

ossler, T. (2010). Reconstruc-

tion of electronic signatures from eDocument print-

outs. Computers and Security, 29(5):523 – 532. Chal-

lenges for Security, Privacy and Trust.

Leitold H., Hollosi A., P. R. (2002). Security Architecture

of the Austrian Citizen Card Concept. In Proceed-

ings of 18th Annual Computer Security Applications

Conference (ACSAC’2002), Las Vegas, 9-13 Decem-

ber 2002. pp. 391-400, IEEE Computer Society, ISBN

0-7695-1828-1, ISSN 1063-9527., pages 391–400.

OASIS (2007). Digital Signature Service Core Protocols,

Elements, and Bindings Version 1.0. http://docs.oasis-

open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf.

Ramsdell, B. and Turner, S. (2010). Secure/Multipurpose

Internet Mail Extensions (S/MIME) Version 3.2 Mes-

sage Speciﬁcation. http://tools.ietf.org/html/rfc5751.

RSA Laboratories (1993). PKCS#7: Cryptographic Mes-

sage Syntax Standard. ftp://ftp.rsasecurity.com/pub/

pkcs/ascii/pkcs-7.asc.

Stranacher, K. and Kawecki, T. (2012). Interoperable Elec-

tronic Documents. In Scholl, Flak, Janssen, Macin-

tosh, Moe, Sbø, and Wimmer, editors, Electronic Gov-

ernment and Electronic Participation - Joint Proceed-

ings of Ongoing Research and Projects of IFIP EGOV

and IFIP ePart 2012, volume 39 of Informatik, pages

81 – 88. Trauner.

The European Parliament and the Council of the Eu-

ropean Union (2000). Directive 1999/93/EC

of the European Parliament and of the Coun-

cil of 13 December 1999 on a Community

framework for electronic signatures. http://

eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:

L:2000:013:0012:0020:EN:PDF.

The European Parliament and the Council of the Euro-

pean Union (2006). Directive 2006/123/EC of the

European Parliament and of the Council of 12 De-

cember 2006 on services in the internal market. http://

eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:

L:2006:376:0036:0068:en:PDF.

World Wide Web Consortium (2008a). Web Con-

tent Accessibility Guidelines (WCAG) 2.0. http://

www.w3.org/TR/WCAG/.

World Wide Web Consortium (2008b). XML Signa-

ture Syntax and Processing (Second Edition). http://

www.w3.org/TR/xmldsig-core/.

Zefferer, T., Tauber, A., Zwattendorfer, B., and Knall,

T. (2011). Secure and Reliable Online-Veriﬁcation

of Electronic Signatures in the Digital Age. In

Bebo White, P. I. and Santoro, F. M., editors, Proceed-

ings of the IADIS International Conference WWW/IN-

TERNET 2011, pages 269 – 276.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

334