The Austrian Governmental eDelivery System Technical Aspects Ankara, March 17th, 2015 Christian Maierhofer, EGIZ The E-Government Innovation Center is

The Austrian Governmental eDelivery System

Technical Aspects

Ankara, March 17th, 2015

Christian Maierhofer, EGIZ

The E-Government Innovation Center is a joint initiative of the Federal Chancellery and Graz University of Technology

Christian Maierhofer, EGIZ Ankara, March 17th, 2015

eGovernment Innovation Center (EGIZ)

Joint initiative with theFederal Chancellery (FCA)

Started in 2005

Head: R. Posch (CIO of FCA)

Fields of Research:

Electronic Signatures

Electronic Mandates

Electronic Delivery

Cloud Security

Interoperability eGovernment


Agenda

Overview – eID in Austria

eDelivery – Electronic Delivery Process

eDelivery – A sending application‘s perspective


Agenda




e-Tresor

Private sector applications

Other private sector applications

Business Service Portal

Public sector applications

...Other public sector

applicationsDelivery services

(http://zustellung.gv.at)HELP.gv.at

...

MOA-ID/SP/SS

Modules for online applicationsfor service providers

Source Pin Register

Mandate data base

Online mandate serviceMandate management

sPIN, ssPIN

Mandate Information

ssPIN resp. encrypted ssPIN

Electronic mandate information

Central register of residents

Additional registers

Supplementary register for natural persons

Supplementary register for others concerned

Register of company names Register of associations

Basis register for natural personsSource data for natural persons

Basis register for non-natural personsSource data for non-natural persons

Central business registerBusiness registerRegister of civil status

Other Registers

Identity Data for natural Persons Identity Data for non-natural Persons

bPK1 ssPIN2 ssPIN3ssPIN1 ssPIN... ssPIN3

Identity data


External mandate data

Business register + CRR + SRnP

Legal frame work for eGovernment in Austria

Common ICT strategy(Coordination: Platform Digital Austria)

ssPIN...

€eBanking

ssPIN1 ssPIN2

Insurances

Natural persons

Non-natural persons

Professional representative

Register of buildings and residences

Legal Basis and Controlling

e-Tresor

Private sector applications

Other private sector applications


Public sector applications

...Other public sector

applicationsDelivery services

(http://zustellung.gv.at)HELP.gv.at

...

Smart Card Mobile Phone Signature

Citizen Card Conceptfor citizens

STORK VIDP

Identity Link

MOA-ID/SP/SS

Modules for online applicationsfor service providers

Natural persons Natural Persons(nat. person as representative of

another nat. person)

Companies(nat. person as representative of

non-nat. person)

bPK1 ssPIN2 ssPIN3ssPIN1 ssPIN... ssPIN3

Identity data

ssPIN...

€eBanking

ssPIN1 ssPIN2

Insurances


The Austrian Citizen Card

The term “Citizen Card” denotes a concept not a concrete implementation

Technological independent

The Citizen card may be implemented on the base of

Smart cards, like the health insurance card (eCard)

Mobile phones, like the Mobile phone signature(used by 470.000 citizens ~ 5.6%)


The Austrian Citizen Card (§ 4 Par. 1 E-GovG)

The Citizen Card is used to prove the unique identity of an applicant and the authenticity of an electronic submission.

Create qualified electronic signaturesLegally equal to handwritten signatures

So it is:

Electronic Identity document and

Signature on the Internet


Legal Framework

Advanced Electronic Signature

§21. ‘electronic signature’ means data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication;

§22. ‘advanced electronic signature’ means an electronic signature which meets the following requirements:(a) it is uniquely linked to the signatory;(b) it is capable of identifying the signatory;(c) it is created using means that the signatory can maintain under his sole control; and(d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable;

Electronic Signature


Legal Framework

Qualified Electronic signature

Legal Effects

Equivalent to handwritten signatures – except a few cases (e.g. family law)

§23a. advanced electronic signatures which are based on a qualified certificate and which are created by a secure-signature-creation device

§5(a) satisfy the legal requirements of a signature in relation to data in electronic form in the same manner as a hand-written signature satisfies those requirements in relation to paper-based data; and(b) are admissible as evidence in legal proceedings.


The Austrian Citizen Card

§ 4 Par. 4 E-GovG:

The authenticity of an electronically filed document is provided using an electronic signature

§ 4 Par. 2 E-GovG:

The unique identification of a natural person is provided by the source PIN (sPIN)

Technical representation: Identity Link


Identity Link

XML structure, signed by the Source PIN Register Authority (SRA), that uniquely identifies a person.

This structure is bound to the public keyfrom the qualified certificate and includes:

sPIN

Personal data

Name, birthday

Public key (from qualified certificate)

Signature from the SRA

The private key is stored ona secure token

...<saml:SubjectConfirmationData> <pr:Person xsi:type="pr:Physical <pr:Identification> <pr:Value>123456789012</pr:V <pr:Type>http://reference.e-g </pr:Identification> <pr:Name> <pr:GivenName>Herbert</pr:Given <pr:FamilyName>Leitold</pr:Fami </pr:Name>...<saml:Attribute AttributeName="CitizenPublicKey" ... <dsig:RSAKeyValue><dsig:Modulus>snW8OLCQ49qNefems...<dsig:Siganture>...


Identification

Central Register of Residents (CRR)Every natural person is uniquely identified by the CRR number

Source PIN (sPIN)Calculation based on encrypted CRR-ID

May only be decrypted by the Source Pin Register Authority (SRA)

May NOT be directly used for identification

May only be stored (persistent) on the Token (SSCD)

Sector Specific PIN (ssPIN)Based on non-invertible derivation from the sPIN

Calculated for a specific sector the online service operates in


ssPIN Generation

ssPIN generation only possible using the person’s Citizen Card.

sPIN from the Citizen Card required

Non invertible derivation

ssPIN ↛H sPIN

ssPIN_A ↛H ssPIN_B

Not Invertible!

5 3 3

1 2 3

6 2 0

sPIN

ssPIN_A ssPIN_B

e.g. Sector Taxes e.g. Sector Health


Application Login

MOA-ID(Identity Provider)

Online application

Request Access to Application

Citizen Card authentication- Read Identity Link- Calculate ssPIN- Sign Authentication Data

Authentication RequestAuth. Data Response

Provide Resource


Online Mandates – Why?

Alice allows Bob to act on behalf of herself

Alice Bob

Signed Mandate

Online application

- Representative- Access rights- Allowed

applications

Mandate Database



Bilateral authorizationFor certain

actions



Bridge between non-natural and natural

persons

Company representative

Association representative


actions



Professional representation

Accountant

LawyersOfficial representative

Bridge between non-natural and natural

persons

Company representative

Association representative


actions


Online Mandates - Architecture

SourcePIN Register Authority (SRA)

MOA-ID

Representative (Proxy)

Application

MandatorMIS

Selection Legal Persons

Bilateral

Business Register

Company RegisterZVR ERsB

Legal Mandates

Business Register Portal(USP)

Delegated (“Gewillkürte”) Mandates


Electronic Online Mandates

Fully automated online electronic mandate system

Based on Citizen Card identificationbut mandates NOT stored on the card

Mandates are stored by a trusted authority

Mandates for natural and non-natural persons

No paper-based application required

Just-in-Time generationData of mandatory (sPIN)

Define constraints

No revocation required


HELP.gv.at and USP.gv.at in numbers

In April 2014 HELP.gv.at and USP.gv.at had 1.224.439 visits.

In April 2014 4.500.845 pages were accessed via HELP.gv.at and USP.gv.at had.

Average dwell time on website: 5.06 minutes

180 Live situations (e.g. marriage, passport,…)

3.000 textual pages of content, 700 terms


HELP.gv.at and USP.gv.at in numbers

In April 2014 HELP.gv.at and USP.gv.at had 1.224.439 visits.

In April 2014 HELP.gv.at and USP.gv.at had 4.500.845 page impressions.

Average dwell time on website: 5.06 minutes

180 Live situations (e.g. marriage, passport,…)

3.000 textual pages of content, 700 terms

About 424 counters within public

authorities would have to be

available 7 days a week @ 24 hours

a day to overcome this inrush…


Agenda





eDelivery – ComponentseDelivery applications

Proof of delivery

High quality authenticationprovided by Austriancitizen card

Central lookup serviceHolds all recipient data

Delivery agents/serviceProvide electronicmailboxes torecipients Delivery Agent 1 Delivery Agent 2 Delivery Agent n

eDeliveryApplication 1


eDeliveryApplication n

Central Lookup Service


Application tier

Broker tier

Delivery tier

eDelivery – Components

Delivery Agent 1 Delivery Agent 2 Delivery Agent n






Application tier

Broker tier

Delivery tier







LDIF(LDAP)


Application tier

Broker tier

Delivery tier


Delivey Agent 1 Delivery Agent 2 Delivery Agent n





LDIF(LDAP)ssPIN_ZU Name Date of Birth

… DeliveryAgent-URL

Doc Formats

Encryption Cert

ae231d34 Alice 11.1.1999 da1.delivery.at pdf, xml, txt

----

ae231d34 Alice 11.1.1999 da2.delivery.at pdf MIIExjCCA66gAwIBA….

2988dfed Bob 22.2.1990 da1.delivery.at pdf, xml, txt

----


Application tier

Broker tier

Delivery tier







??

?


Application tier

Broker tier

Delivery tier


Delivey Agent 1 Delivery Agent 2 Delivery Agent n





??

?

→ Necessary because no domain name based addressing model

→ Unique ID & Demographics

→ With which delivery agent is a recipient registered?


Application tier

Broker tier

Delivery tier







Application tier

Broker tier

Delivery tier






No intra-provider communication


AT eDelivery – an example


eDelivery Application 1







Precondition: Central Lookup Service holds all recipient data from all Delivery Agents



?

Send Query for recipient:• ssPIN_ZU or• Name and date of birth or• Name and notification email or• Name and postal address






?




HTTPs GET Request

XML over HTTPs Response



?

Answer contains:• URL of Delivery Agent(s) the recipient is registered

with• Usable document formats• Optionally encryption certificate




OK X X



?

Answer contains:• URL of Delivery Agent(s) the recipient is registered

with• Usable document formats• Optionally encryption certificate




OK X X

If recipient is registered with multiple DAs:

► Prefer accounts with encryption certificate

► Otherwise freedom of choice



Zustell-Kopf

?Transmit delivery to delivery agent.



OK X X



Zustell-Kopf




OK X X



Zustell-Kopf




OK X X



@

Recipient must immediately be informed via e-mail or SMS when a new delivery has been received

Delivery Agent 1




Pick-up by logging in at the web-portal of the delivery agent.

Receipt must be carried out using the Austrian citizen card by signing a delivery confirmation/proof of receipt.

Delivery Agent 1




The delivery can now be opened or saved on the local computer.

Delivery agent portal functions are very similar to web-mail systems

Delivery Agent 1



Agenda





Component on sender side

Sender needs a technical application ensuring the connection to

Central Lookup ServerQuery recipient

Delivery AgentTransmission of eDelivery

Delivery Agent

Central Lookup Server

?

eDelivery Application


Component on sender side

Sender needs a technical application ensuring the connection to

Central Lookup ServerQuery recipient

Delivery AgentTransmission of eDelivery

eDelivery clientsOpen source (MOA-ZS)

Propietary solutions

…Delivery Agent

Central Lookup Server

?

eDelivery Application

ED-Client


Delivery Software MOA-ZSMOA-ZS is a open source middleware for senders

Web service interface for simple integration in backend applications

Covers all necessary steps

Acceptance of delivery documents from backend applications

Central lookup service query

Forward documents todelivery service providers

Reception and processing of delivery confirmations


MOA-ZS in a nutshell (1)

BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service

CentralLookupService

OK

X

XWeb service

oid



BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service


OK

X

X

Forwarding the deliver request – recipient address as:

a) Delivery-ssPIN (ssPIN[ZU])b) Name + an address registered at the delivery service (electronic or postal)

[ + birthday at RSa quality]c) Name + postal address | birthday + ssPIN of the own sector (ssPIN[ZU] is

calculated via the SourcePin Register)

1

oid


MOA-ZS – Acceptance of a document



BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service


OK

X

X

Forwarding the deliver request – recipient address as:

a) Delivery-ssPIN (ssPIN[ZU])b) Name + an address registered at the delivery service (electronic or postal)

[ + birthday at RSa quality]c) Name + postal address | birthday + ssPIN of the own sector (ssPIN[ZU] is

calculated via the SourcePin Register)

1

oid

SourcePIN

Register

?



BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service


OK

X

X

Querying the central lookup serivce

oid

2 3


Central Lookup Service - QueryTransport level

SSL client authentication (Gov-OID)

Request typesSingle- / Bulk request

Combining identity attributes(Encrypted) delivery-ssPIN (Sector “ZU”) respectively SourcePin (non-natural persons)

Name + birthday

Name + notification address (email)


Query- ExampleSingle-Query(HTTP-GET)

https://zkopf.zustellung.gv.at/Query?givenName=MAx&sn=Mustermann&[email protected]

Bulk-Query (SOAP Web-Service)

https://zkopf.gv.at/Query?givenName=MAx&sn=Mustermann&[email protected]




Central Lookup Service - Reply- Not registered

- Temporarily not registered

not reachable

reachable

- Delivery-Token

- Recipient’s ID + billing data

- Address of the delivery service

- Accepted data formats of the recipient

- Possible encryption certificate

If more delivery services have to be considered:

- Prefer the service where the user has configured an encryption certificate; else sender’s can freely choose


Response - Example



BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service


OK

X

X

Forwarding to the delivery service

4

5

oid


Forward to Delivery ServiceTransport level

SSL client authentication (administration-OID)

DataDelivery token (ID + billing data)

Address for delivery confirmation (email, WS)

Sender’s data

Meta data

Subject

Delivery ID

Delivery quality


Example



BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service


OK

X

X

MOA-ZS returns OK to the application, if the delivery was successful.

6

oid



BackendApplication

MOA-ZS

Delivery service

Delivery service

Delivery service


OK

X

X

Feedback about the delivery success – optional acknowledgement of receipt – is either sent directly to the special application or (if configured) to MOA-ZS.

7

oid


Delivery Confirmation - Example


Benefits for AuthoritiesMay be delivered electronically with delivery confirmation (RSa or RSb)

May be delivered electronically without delivery confirmation (standard letter quality)

Document is considered to be delivered (Zustellwirkung) without being picked-up by the recipient

Effective date of delivery is always documented for authorities(electronic advice of delivery); for instance the effective data of pickup of the document by the recipient (using her electronic signature)

Delivery confirmation is sent back to the sending authority by the delivery service.

Authority may automatically process this advice of delivery respectively assign it to an act.


Benefits for Authorities (2)

Fee for governmental deliveries (to be paid by the delivering authority):

Half of the standard letter postage + VAT = 0,37 Euro

Possible postal notification fee = 0,744 Euro

Max. 1,116 Euro for RSa or RSb

Conventional: 4,75 Euro (RSa) respectively 2,65 Euro (RSb) + additional costs (print, enveloping, …)


Citizen‘s Point of View

1. Document arrives at the delivery service

2. Email notification is sent to recipient

3. Login mobile signature or citizen card (respectively automatically triggered signature); acknowledgement of receipt gets signed

4. Check document, store or forward it

2

1

4

3


Notifications issued by the Delivery Service

1. Electronic notification (immediately to all electronic registered addresses)

2. Electronic notification (if not picked up within 48 hours)

3. Postal notification (if not picked up within the next 24 hours and the recipient has registered a delivery address therefor)

2

3

1


Example


Mail Pickup according to § 35

POP.deliveryservice.xy.at

STANDARD MAILCLIENT (POP)

LOGIN TO DELIVERYBROWSER+CITIZEN CARD

PICKUPMAILCLIENT + CERTIFICATE

Identification based on the configure SSL client certificate.

Delivery confirmation based on SSL handshake (of the mail client or the browser) according to §35 (3) ZustG. E.g. simple clicking a Link in the notification email.


Dual DeliveryBrings together traditional delivery with electronic delivery

Intention: deliver electronically

If electronic delivery not possible: Postal delivery (Printing, Enveloping, …)

ONE interface


Dual Delivery - Architecture


Dual Delivery

Senders need to register at dual delivery systemUnique profile id

Address data

Billing details

Authentication information (TLS client authentication)

Steps of dual deliveryAddressing in advance (which delivery channels are supported?)

Delivery request

Single or Bulk requests

Delivery receipts processing

Communication with printing channel


Delivery fee trend - Styria

1.5.2011POST-AG delivery fee increased

1.7.20112POST-AG delivery fee increased

Start of dual delivery

Budget for deliveryfees

€ 210.000 per year

€ 170.000 per year

€ 610.000 per year

DI. Herbert Huettenbrenner

Thank you for your attention…

Ankara, March 17th, 2015

Christian Maierhofer, EGIZ

The E-Government Innovation Center is a joint initiative of the Federal Chancellery and Graz University of Technology


Additional Information


Example sPIN Calculation

Base number 000247681888(E.g.: CPR-number, 12 decimals)

Binary representation

00 0E C3 53 60(5 Byte, hexadecimal representation)

Expand to 128 bit 00 0E C3 53 60 FF 00 0E C3 53 60 00 0E C3 53 60 (16 Byte, Seed value set to e.g. 0xFF)

Triple-DES encryption, hexadecimal

42 AD 37 74 FA E0 70 7B 31 DC 6D 25 29 21 FA 49 (16 Byte)

Source PIN, Base64

Qq03dPrgcHsx3G0lKSH6SQ== (24 digits)


Example: ssPIN Calculation

sPIN, Base64 Qq03dPrgcHsx3G0lKSH6SQ== (24-digit)

Sector code BW (ISO-8859-1, E.g.: Bauen und Wohnen)

Input data for hash value calculation

Qq03dPrgcHsx3G0lKSH6SQ==+urn:publicid:gv.at:cdid+BW

Hash value 8FF3717514 21A7EB4DC8 4F56847741 498BB2DE10(5 x 32bit; hexadecimal representation)

ssPIN, Base64 j/NxdRQhp+tNyE9WhHdBSYuy3hA= (28-digit)


Mobile Phone Signature

IdL and asymmetric key are stored by A-TRUST and protected by a hardware security module (HSM)

For the signature creation a TAN is sent to the citizen via SMS

This TAN must be entered during the signature creation process

HSM communicates directly with an SMS gateway to send the TAN


Operator of the mobile phone solution User

Mobile Phone Signature - Components

User’s mobile phone

User

Password:********



Mobile Phone Signature - Components

Key databaseSignature creation data is encrypted using a key consisting of at least:- Secret password- Secret HSM key

SMS Gateway

Web-Frontend

HSM- Creation of signature

creation data- Decryption of stored

signature creation data- Creation of qualified

electronic signatures

Password:********



Mobile Phone Signature – Registration Process

Password:********




Announce mobile nr.

Choose password

Password Assurance of identity

Mob-nr.Verify phone ownership:

Generate one-time code

Send code via SMS

Code

Password:********




Code

Co

de

Generate and encrypt the signature creation data with at least:- HSM key- Key derived from

password

Stored encrypted datain the database

Ownership verified

Code

Verify ownership

Password:********



Generate and encrypt the signature creation data with at least:- HSM key- Key derived from

password

Stored encrypted datain the database

Ownership verified


Code

Co

de

Code

The usage of the signature creation data is only possible1. within the HSM and2. after the signature password has been entered by the

signatory

Password:********



Mobile Phone Signature – Signature Process

Password:********



Application issued a signature request

User is redirected to signature website

Password

Enter mobile nr.

Mob-nr.

Enter password

Request


Password:********




Calculate hash value of the data to be signed (from request)

Generate one-time code

Send one-time code and hash value via SMS

Code

Affirmation

Display

Password:********

Hash value




Provide one-time code

Code

Co

de

Recovery of the signature creation data from the database with- HSM key- Password-derived key

Signature creation using the signature creation data

Ownership verified

Code

Verify ownership

Password:********



Recovery of the signature creation data from the database with- HSM key- Password-derived key

Signature creation using the signature creation data

Ownership verified


Provide one-time code

Code

Co

de

Code

Verify ownership

Password:********

The one-time code verifies the ownership of the mobile phone

The usage of the signature creation data is only possible1. within the HSM and2. after the signature password has been entered by the

signatory




Signature is returned to the application

SignatureReturn the created XML signature

Password:********

Documents

The Austrian Governmental eDelivery System Technical Aspects Ankara, March 17th, 2015 Christian Maierhofer, EGIZ The E-Government Innovation Center is