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, EGIZAnkara, March 17th, 2015 eGovernment Innovation Center (EGIZ) Joint initiative with the Federal Chancellery (FCA) Started in 2005 Head: R. Posch (CIO of FCA) Fields of Research: Electronic Signatures Electronic Mandates Electronic Delivery Cloud Security Interoperability eGovernment

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Agenda Overview – eID in Austria eDelivery – Electronic Delivery Process eDelivery – A sending application‘s perspective

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Agenda Overview – eID in Austria eDelivery – Electronic Delivery Process eDelivery – A sending application‘s perspective

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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 citizens ~ 5.6%)

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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 signatures Legally equal to handwritten signatures So it is: Electronic Identity document and Signature on the Internet

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Legal Framework Advanced Electronic Signature §2 1. ‘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; §2 2. ‘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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Legal Framework Qualified Electronic signature Legal Effects  Equivalent to handwritten signatures – except a few cases (e.g. family law) §2 3a. 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.

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Identity Link XML structure, signed by the Source PIN Register Authority (SRA), that uniquely identifies a person. This structure is bound to the public key from the qualified certificate and includes: sPIN Personal data Name, birthday Public key (from qualified certificate) Signature from the SRA The private key is stored on a secure token... <pr:Person xsi:type="pr:Physical </pr:V Herbert</pr:Given Leitold</pr:Fami... snW8OLCQ49qNefems...

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 ssPIN Generation ssPIN generation only possible using the person’s Citizen Card. sPIN from the Citizen Card required Non invertible derivation ssPIN ↛ sPIN ssPIN_A ↛ ssPIN_B Not Invertible! e.g. Sector Taxese.g. Sector Health

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application Login MOA-ID (Identity Provider) MOA-ID (Identity Provider) Online application Request Access to Application Citizen Card authentication -Read Identity Link -Calculate ssPIN -Sign Authentication Data Authentication Request Auth. Data Response Provide Resource

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Online Mandates – Why?  Alice allows Bob to act on behalf of herself AliceBob Signed Mandate Online application -Representative -Access rights -Allowed applications Mandate Database

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Online Mandates – Why? Bilateral authorization For certain actions

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Online Mandates – Why? Bridge between non- natural and natural persons Company representative Association representative Bilateral authorization For certain actions

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Online Mandates – Why? Professional representation Accountant Lawyers Official representative Bridge between non- natural and natural persons Company representative Association representative Bilateral authorization For certain actions

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Online Mandates - Architecture

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Electronic Online Mandates Fully automated online electronic mandate system Based on Citizen Card identification but 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 generation Data of mandatory (sPIN) Define constraints No revocation required

Christian Maierhofer, EGIZAnkara, March 17th, 2015 HELP.gv.at and USP.gv.at in numbers In April 2014 HELP.gv.at and USP.gv.at had visits. In April 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,…) textual pages of content, 700 terms

Christian Maierhofer, EGIZAnkara, March 17th, 2015 HELP.gv.at and USP.gv.at in numbers In April 2014 HELP.gv.at and USP.gv.at had visits. In April 2014 HELP.gv.at and USP.gv.at had page impressions. Average dwell time on website: 5.06 minutes 180 Live situations (e.g. marriage, passport,…) textual pages of content, 700 terms About 424 counters within public authorities would have to be available 7 days a 24 hours a day to overcome this inrush…

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Agenda Overview – eID in Austria eDelivery – Electronic Delivery Process eDelivery – A sending application‘s perspective

Christian Maierhofer, EGIZAnkara, March 17th, 2015 eDelivery – Components eDelivery applications Proof of delivery High quality authentication provided by Austrian citizen card Central lookup service Holds all recipient data Delivery agents/service Provide electronic mailboxes to recipients Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n Central Lookup Service

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n Central Lookup Service

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n Central Lookup Service LDIF(LDAP)

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivey Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n Central Lookup Service LDIF(LDAP) ssPIN_ZUNameDate of Birth …DeliveryAgent- URL Doc Format s Encryption Cert ae231d34Alice da1.delivery.atpdf, xml, txt ---- ae231d34Alice da2.delivery.atpdfMIIExjCCA6 6gAwIBA…. 2988dfedBob da1.delivery.atpdf, xml, txt ----

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n Central Lookup Service ? ? ?

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivey Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n Central Lookup Service ? ? ? → Necessary because no domain name based addressing model → Unique ID & Demographics → With which delivery agent is a recipient registered? → Necessary because no domain name based addressing model → Unique ID & Demographics → With which delivery agent is a recipient registered?

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Application tier Broker tier Delivery tier eDelivery – Components Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 eDelivery Application 1 eDelivery Application 2 eDelivery Application 2 eDelivery Application n eDelivery Application n No intra-provider communication

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 Central Lookup Service

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 Central Lookup Service Precondition: Central Lookup Service holds all recipient data from all Delivery Agents

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example ? Send Query for recipient: ssPIN_ZU or Name and date of birth or Name and notification or Name and postal address Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 Central Lookup Service

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example ? Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 Central Lookup Service HTTPs GET Request XML over HTTPs Response HTTPs GET Request XML over HTTPs Response

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example ? Answer contains: URL of Delivery Agent(s) the recipient is registered with Usable document formats Optionally encryption certificate Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 Central Lookup Service OK X X

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example ? Answer contains: URL of Delivery Agent(s) the recipient is registered with Usable document formats Optionally encryption certificate Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 Central Lookup Service OK X X If recipient is registered with multiple DAs: ►Prefer accounts with encryption certificate ►Otherwise freedom of choice If recipient is registered with multiple DAs: ►Prefer accounts with encryption certificate ►Otherwise freedom of choice

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example Zustell -Kopf ? Transmit delivery to delivery agent. Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 OK X X

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example Zustell -Kopf ? Transmit delivery to delivery agent. Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 OK X X

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example Zustell -Kopf ? Transmit delivery to delivery agent. Delivery Agent 1 Delivery Agent 2 Delivery Agent n eDelivery Application 1 OK X X

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an Recipient must immediately be informed via or SMS when a new delivery has been received Delivery Agent 1 eDelivery Application 1

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example 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 eDelivery Application 1

Christian Maierhofer, EGIZAnkara, March 17th, 2015 AT eDelivery – an example 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 eDelivery Application 1

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Agenda Overview – eID in Austria eDelivery – Electronic Delivery Process eDelivery – A sending application‘s perspective

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Component on sender side Sender needs a technical application ensuring the connection to Central Lookup Server Query recipient Delivery Agent Transmission of eDelivery Delivery Agent Central Lookup Server ? eDelivery Application

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Component on sender side Sender needs a technical application ensuring the connection to Central Lookup Server Query recipient Delivery Agent Transmission of eDelivery eDelivery clients Open source (MOA-ZS) Propietary solutions … Delivery Agent Central Lookup Server ? eDelivery Application ED-Client

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Delivery Software MOA-ZS MOA-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 to delivery service providers Reception and processing of delivery confirmations

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (1) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup Service OK X X Web service oid

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (2) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS – Acceptance of a document

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (3) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup 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 Source PIN Registe r ?

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (5) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup Service OK X X Querying the central lookup serivce oid 23

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Central Lookup Service - Query Transport level SSL client authentication (Gov-OID) Request types Single- / Bulk request Combining identity attributes (Encrypted) delivery-ssPIN (Sector “ZU”) respectively SourcePin (non- natural persons) Name + birthday Name + notification address ( )

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Query- Example Single-Query(HTTP-GET) Bulk-Query (SOAP Web-Service)

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Response - Example

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (5) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup Service OK X X Forwarding to the delivery service 4 5 oid

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Forward to Delivery Service Transport level SSL client authentication (administration-OID) Data Delivery token (ID + billing data) Address for delivery confirmation ( , WS) Sender’s data Meta data Subject Delivery ID Delivery quality

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Example

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (4) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup Service OK X X MOA-ZS returns OK to the application, if the delivery was successful. 6 oid

Christian Maierhofer, EGIZAnkara, March 17th, 2015 MOA-ZS in a nutshell (6) Backend Application Backend Application MOA-ZS Delivery service Central Lookup Service Central Lookup 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Delivery Confirmation - Example

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Benefits for Authorities May 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.

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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, …)

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Citizen‘s Point of View 1.Document arrives at the delivery service 2. 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Example

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Mail Pickup according to § 35 POP.deliveryservice.xy.at STANDARD MAILCLIENT (POP) LOGIN TO DELIVERY BROWSER+CITIZEN CARD PICKUP MAILCLIENT + 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 .

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Dual Delivery Brings together traditional delivery with electronic delivery Intention: deliver electronically If electronic delivery not possible: Postal delivery (Printing, Enveloping, …) ONE interface

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Dual Delivery - Architecture

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Dual Delivery Senders need to register at dual delivery system Unique profile id Address data Billing details Authentication information (TLS client authentication) Steps of dual delivery Addressing in advance (which delivery channels are supported?) Delivery request Single or Bulk requests Delivery receipts processing Communication with printing channel

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Delivery fee trend - Styria POST-AG delivery fee increased POST-AG delivery fee increased Start of dual delivery Budget for delivery fees € per year € per year € 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Additional Information

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Example sPIN Calculation Base number (E.g.: CPR-number, 12 decimals) Binary representation 00 0E C (5 Byte, hexadecimal representation) Expand to 128 bit00 0E C FF 00 0E C E C (16 Byte, Seed value set to e.g. 0xFF) Triple-DES encryption, hexadecimal 42 AD FA E0 70 7B 31 DC 6D FA 49 (16 Byte) Source PIN, Base64 Qq03dPrgcHsx3G0lKSH6SQ== (24 digits)

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Example: ssPIN Calculation sPIN, Base64Qq03dPrgcHsx3G0lKSH6SQ== (24-digit) Sector codeBW (ISO , E.g.: Bauen und Wohnen) Input data for hash value calculation Qq03dPrgcHsx3G0lKSH6SQ==+urn:publicid:gv.at:cdid+ BW Hash value8FF A7EB4DC8 4F BB2DE10 (5 x 32bit; hexadecimal representation) ssPIN, Base64j/NxdRQhp+tNyE9WhHdBSYuy3hA= (28-digit)

Christian Maierhofer, EGIZAnkara, March 17th, 2015 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature - Components User’s mobile phone User Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature - Components Key database Signature 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: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Registration Process Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Registration Process Announce mobile nr. Choose password Password Assurance of identity Mob-nr. Verify phone ownership: Generate one-time code Send code via SMS Code Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Registration Process Code Generate and encrypt the signature creation data with at least: -HSM key -Key derived from password Stored encrypted data in the database Ownership verified Code Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Generate and encrypt the signature creation data with at least: -HSM key -Key derived from password Stored encrypted data in the database Ownership verified Mobile Phone Signature – Registration Process Code The usage of the signature creation data is only possible 1.within the HSM and 2.after the signature password has been entered by the signatory Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Signature Process Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Application issued a signature request User is redirected to signature website Password Enter mobile nr. Mob-nr. Enter password Request Mobile Phone Signature – Signature Process Password: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Signature Process 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

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Signature Process Provide one-time code Code 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: ********

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Recovery of the signature creation data from the database with -HSM key -Password-derived key Signature creation using the signature creation data Ownership verified Mobile Phone Signature – Signature Process Provide one-time code Code Verify ownership Password: ******** The one-time code verifies the ownership of the mobile phone The usage of the signature creation data is only possible 1.within the HSM and 2.after the signature password has been entered by the signatory

Christian Maierhofer, EGIZAnkara, March 17th, 2015 Operator of the mobile phone solutionUser Mobile Phone Signature – Signature Process Signature is returned to the application Signature Return the created XML signature Password: ********