Status and Outlook on Electronic Identity in Europe: The Case of Austria

Signaturgesetz - the signature law

SigG is divided in eight sections; following are their most important provisions with regard to e-signatures:

Section #1 defines the individual terms that are used in this legal domain. These term definitions generally (but not always/fully!) correspond to the definitions mandated in the Directive, Art. 2.

This section, inter alia, defines (in Art. 2) the (.1) electronic signature as data, which has been attached or logically associated with other data and serve as a method of authentication; the (.2) signatory is a person or any judicable organization to which (.4) signature-creation data (unique data such as codes [passwords] or private signing keys used to electronically sign data) and (.6) signature-verification data (data such as codes [passwords] or public keys used to verify signed data) have been assigned and which created a signature in its own name or as a proxy; the (.3) advanced electronic signature is a signature dedicated to its signer, which allows its identification, has been created using data which the signer can keep under its sole control and which has been bound to the signed data in a way that any posterior change of the signed data can be detected; the (.3a) qualified electronic signature is an advanced electronic signature created by a (.5) secure signature-creation device (configured soft- or hardware used to handle signature creation data, whereby this soft- or hardware must comply with security requirements imposed by the SigG and subordinate regulations), which is based on a (.9) qualified certificate (a (.8) certificate (i.e. an electronic confirmation that assigns signature-creation data to a person and con-firms its identity), which contains specified data and which has been issued by a certificate-service provider (hereinafter: certificate agency or CA)).

Section #2 contains provisions regarding the validity of the electronic signature in the legal con-text. It incorporates Art. 5 of the Directive, which defines that (1) electronic signatures are valid before law and that (2) advanced electronic signatures based on a qualified certificate – i.e. qualified e-signatures, are equal to handwritten ones.

The provisions in this section explicitly disclose any potential for discriminating before law or questioning of the validity of “simple” e-signatures, which do not base on a qualified certificate, or if such certificate has not been issued by an accredited certificate agency, or if the signature was not created using technology, which complies with provisions further defined in the SigG. These non-discriminative provisions are mandated by Art 5.2 of the Directive.

It is further important to note that qualified e-signatures serve only as temporary equivalents to handwritten signatures where existing law requires the later. Thus, Dumortier [4] emphasizes that qualified e-signatures are only applicable so long as national laws still know the legal con-cept of handwritten signatures; future legislators should therefore be encouraged to foster the use of advanced e-signatures.

Sections #3-6 aim to regulate CAs (Germ.: Zertifizierungsdiensteanbieter - ZDA), i.e. organizations that issue certificates. Initially, these provisions restricted certificate-service providers trough mandatory registration with a controlling authority, whereby CAs had to comply with certain organizational and technical provisions; the controlling authority had permission to prohibit the CA to offer its services if those provisions were found to not be met.

However, Art 3.1 of the Directive clearly forbids any regulative restrictions by national states and therefore crucial provisions of sections #3-6, which initially gave the controlling authority its powers, were annulled in 2008. The resulting regulations are effective only for voluntary accreditation, which gives CAs the guarantee that their products comply with the given advanced requirements and thus their clients’ additional security. Accredited CAs may refer to their accreditation when doing business.

Section #7 equalizes certificates issued by CAs in other EU countries with domestic certificates and defines that certificates issued by non-EU countries are equally valid under the condition that, e.g., the issuing CAs comply with the provisions for voluntary accreditation.

Section #8 contains final provisions that inter alia introduce an ordinance – the Signaturverordnung (SigV), which further regulates the requirements regarding qualified certificates issued by accredited CAs. The SigV is a relevant source for CAs that desire accreditation, as it defines strictly what conditions CAs must fulfil and which technology must be used in order to comply with the legal provisions. Austria is one of only few countries which explicitly defined trough law the specific technology permitted for accredited qualified signature-service providers; this how-ever has only limited significance in the pan-European context, as national law must not prohibit, neither aim to restrict individual solutions beyond the provisions of the Directive.

The Austrian Citizen Card

With the aim to facilitate electronic interaction between citizen and the government, Austria promulgated a dedicated e-government law, the e-Government-Gesetz – hereinafter: e-GovG [12].

E-GovG introduces the Austrian Citizen Card – Bürgerkarte, hereinafter: CC [13], a globally unique [cf. 14] mechanism for providing I-A-S on the citizen-to-government relation. Unlike other European national identification schemes, which often rely on smart-card technology [14], [15], Austria chose a technology- and vendor-neutral approach for the CC. In fact, the CC is only an abstractly defined legal concept [12 Art 4], which bases on the Identity-Link (Personenbindung, hereinafter: IDL) – an electronically signed confirmation provided by the Austrian Data Protection Commission, which confirms that the identity expressed trough the CC corresponds to an identity registered in Austria (which can be also foreign citizen with no residency in Austria).

The CC is defined as a logical unit, which regardless of its implementation binds a qualified e-signature with the Identity-Link […] [12 Art 2.10]; at present, the CC is not closer defined, although provisions exist that would allow the government to regulate details trough an ordinance if required.

Further provisions regulating the IDL are available in the ordinance, which regulates the authority responsible for administering national personal identification numbers (hereinafter: SZR): the Stammzahlenregisterbehördenverordnung. This ordinance inter alia regulates how identities are stored in the particular registries and how they are communicated outwards in case an IDL is requested for embedment into a CC.

According to this ordinance, the SZR must provide a technical interface for embedding the IDL into the CC, as well as a web page for requesting such embedment. As explicitly stated by the ordinance, this technical interface is the only permitted way to embed the IDL, however although the documentation for said interface must be publicly available on SZR’s web site, we could find there neither this documentation, nor the web page for requesting it at the time of writing.

Using a CC is not mandatory, but only one among a potentially infinite number of instances of technologies that comply with the legal provisions for the citizen-to-government interaction. E-GovG does not limit this relation to the use of a CC, but instead requires that access to sensible personal data from a public registry can be granted only to an unambiguously identified re-quester provided that the request can be unambiguously authenticated, whereby proofs for both must be given in electronic form [12 Art 3/II]; the CC in this constellation is therefore only a suggested concept, which however automatically satisfies the conditions and thus facilitates interaction.

Available e-ID carriers / A-Trust

The first provider of e-ID tokens that complied with the provisions for the Austrian Citizen Card (CC) was the Austrian Computer Society, which in 2003 equipped its members with new mem-bership cards with smartcard functionality [20]; the Austrian Computer Society did however not provide CCs directly. Further potential e-ID carriers where disseminated later trough a later generation of ATM cards and mandatory social security cards – the eCard; Aichholzer & Strauß [21] provide an elaborate overview of the CC development and dissemination, as well as its conceptual design.

At present, two carrying technologies exist: smartcard-based CCs (ATM cards, the eCard, student IDs, etc. [23]) and a solution that utilizes one’s mobile phone.

On smartcards, a stored SAML assertions document represents the Identity-Link [24] and two cryptographic key pairs are available for e-signing (one for qualified e-signatures according to Austrian criteria); in order to use the card as a CC, special software must be used, while signing trough popular office applications is theoretically, but not practically possible [25], [26], because advanced elliptic curve cryptography is used, which is not yet popularly supported. The smart-card offers a convenient way to assure multi-factor authentication trough proof of possession and knowledge (the PIN), however it is becoming increasingly inconvenient and unpopular for practical use, as it requires special hard- and software, like smartcard-readers and supporting hosting systems [cf. 23].

A-Trust’s mobile solution, the Handy-Signatur (HS) transforms the user’s mobile phone into a secure-signature-creation-device (SSCD), which assures multi-factor authorization (proof-of-possession: the mobile device, knowledge: shared secret); the HS was designed as part of the STORK project [23]. Mobile e-signing can be achieved twofold [cf. 27]: either by utilizing a special SIM card as the SSCD, as it is done by the Estlandian Mobiil-ID [23], or by using the mobile device as an authentication token, which unlocks the signing module on a remote server, as it is the case with the Handy-Signatur.

An SSCD inter alia must comply with the requirement that it can be hold under the sole control of its owner. In the case of the HS however, the SSCD is not a single physically controllable object anymore, but rather a system that fulfils this condition trough organizational means [28].

In the case of the HS, the cryptographic key pairs are stored in an nShield 500e F31 hardware security module (HSM) on a high security server stored in a safe of A-Trust’s computing center [28]; the user requests access to the CC functionality by sending her phone number and associated password – the shared secret, via HTTPS (using a web form provided by A-Trust) to the server, which responds by sending a time-limited, unique password via SMS to the user’s mobile phone, which the user transmits over HTTPS as the proof of possession information; this one-time-password grants the server’s signing module access to the key pair and the associated Identity-Link SAML assertions in the HSM [23], [28].

Technical recommendations

Several recommendations that regulate the technical characteristics of the Austrian e-ID have been designed, which however have not been issued by relevant democratic bodies and are consequently not binding before law. This deficit of formal legitimacy of the available technical documents however must be viewed in the light of the absolute monopolistic constellation of A-Trust and A-SIT; consequently, the available technical specifications must be seen as the documentation for A-Trust’s instantiations of the CC, which is relevant for advanced users and developers who require dealing with existing solutions.

The formal issuer of technical conventions is a non-personified association of federal, regional and local governments that bases on a mutual agreement on cooperation in the use of ICT – the Kooperation Bund/Länder/Gemeinden; this association publishes its agreed-upon conventions on http://reference.e-government.gv.at. Since 2005, e-government-related issues are coordinated by the federal chancellor trough the unit Platform Digitales Österreich (Platform Digital Austria; PDA; http://www.digitales.oesterreich.gv.at), whose chair is the Chief Information Officer (CIO).

Complete technical documentation can be found online at two sources (English translations are partly provided):

1. http://www.buergerkarte.at/konzept/
2. http://reference.e-government.gv.at/KONVENTIONEN.1116.0.html

The available documentation describes a recommendation how to instantiate the CC (“CC Specifications”) [29], the format of the Identity-Link [24] and the protocol for requesting the Identity-Link [30].

(It is interesting to observe that all leading people who are involved in designing the Austrian CC technical recommendations, as well as those involved in voluntary accreditation of the CC, have their professional roots in the Technical University of Graz; based on this finding, one might conclude that the Austrian e-ID, as the main pillar of Austrian e-Gov, is governed by a single “clan”. Kubicek & Noack [6] note, that such clans can have positive influence on the development process, they do however not comment this issue from other, more democratic points of view.)

The CC-specifications recommendation [29] describes an abstract model which consists of three stakeholders: the citizen, the CC-environment and the application.

The CC-environment (CCE) is an information system that encapsulates the concrete CC and enables the consuming application access to the CC’s functionality. This model allows an application to consume many different CC tokens with no need to adapt to their special requirements, be-cause the CCE takes care of this.

Interaction between applications and the CCE is provided trough an exchange of specified XML requests and responses over either a TCP/IP (or SSL/TLS) or HTTP (HTTPS) binding (the “Security Layer”); in the first case, the requests are transmitted directly to an Internet socket, in the later, the request is transmitted via a HTML form. Applications can request the creation and verification of e-signatures (CMS and XMLDSig), encryption and decryption to/from CMS and XMLEnc, calculation and verification of hashes, and the access to associated data storage provided as part of the CC concept – to read e.g. the Identity-Link or to write application-specific data.

The communication between the CCE and the user is conducted via the User-Interface (Benutzerschnittstelle; UI). The CC specifications contain provisions that regulate how the UI must behave, e.g. that it must present to the citizen the document before signing it; further, CC specifications regulate that for visualizing content, a limited XHTML 1.1 and CSS 2 must be used.

Several end-user CCEs are available – three commercial and one open-source CCE are listed on A-SIT’s CC-dedicated web site http://buergerkarte.at. The open-source MOCCA [31], [32] is considered as the most advanced option and provides integrated support for many foreign e-ID cards, among them the Belgian BELPIC, Estonian ESTID, as well as Italian, Icelandic, Lithuanian, Swedish, Swiss, Portuguese e-ID cards [33], [34] – several foreign e-ID solutions (not including the Swiss one) have been equalized with the CC by a decree of the federal chancellor in 2010 [35].

Another solution worth mentioning are the open-source Modules for Online-Applications – MOA [36], which are formally provided by the Austrian Federal Chancellery. MOA provide means for creating and verifying e-signatures and reading the IDL, however they slightly differ from the formal CC specifications and offer advanced possibilities for developers, such as a SOAP and Java API. An illustrative use-case with a Lichtenstein e-ID has been described by Ivković & Stranacher [33].