Download pdf - eIdentity & eSignature

Donau-Universität KremsDr. Peter Parycek, Zentrum für E-Government

Erwartungen E-Identität und E-Signatur in der PraxisÜberblick über den aktuellen Stand in den europäischen Staaten

Dr. Peter Parycek, MSc - ZentrumsleiterZentrum für E-Government an der Donau-Universität Krems


Donau-Universität Krems Staatliche Weiterbildungsuniversität

• 16 Departments

• 4100 Studierende


Zentrum für E-Government & Zentrum für praxisorientierte Informatik: Lehre

Universitätsprogramme:Professional MSc E-GovernmentProfessional MSc IT ConsultingInformation Security Management, MScProfessional MSc IT in Healthcare and Life ScienceProfessional MSc Supply-Chain ManagementProfessional MSc Strategie, Technologie und ganzheitliches Management

Kooperationen in Deutschland: IHKIG Metall


Zentrum für E-Government & Zentrum für praxisorientierte Informatik: Projekte


Agenda

1. Überblick: eSig = eID?

2. Länderansätze

3. Internationale Interoperabilität


eID & eSigeID & eSig

1. eSig = eID ?


eSig = eID ?


eSig


Zweck der eSig

Authentizität von Urheber & Daten

Zuordnung der Daten zum Unterzeichner

Schutz vor Abstreiten durch Unterzeichner

Sicherung der signierten Daten vor Manipulation• am Übertragungsweg

• durch den Empfänger


Signatur-Richtline der Europäischen Kommission

eSig: Rechtliche Grundlage

Nationale Signaturgesetzeder Mitgliedsstaaten


Arten Elektronischer Signaturen„Einfache“ elektronische Signatur

dient der Feststellung der Identität des Signatorsauch für juristische Personen möglich

„Fortgeschrittene“ elektronische Signaturist ausschließlich dem Signator zugeordnetermöglicht die Identifikation des Signatorswird mit Mitteln erstellt, die der Signator unter seiner alleinigen Kontrolle halten kannev. nachträgliche Veränderungen wären feststellbar auch für juristische Personen möglich

„Qualifizierte“ elektronische Signaturist eine fortgeschrittene Signaturberuht auf qualifiziertem Zertifikat (nur für natürliche Personen!)wird mit einer sicheren Signaturerstellungseinheit (SSCD) erzeugt


eID


KEINE eID Richtline!

eID: Rechtliche Grundlage ?

Teilweise gibt es nationale Bestimmungen


eID Konzepte

Username & PasswortSoftware ZertifikatUSB LösungenSmart-Card LösungenVirtual Smart-Card Lösungen


APP 1flaches MODELL

sektorales MODELL getrenntes MODELL

ID

APP 2ID

APP 3ID

APP 1ID1

APP 2ID2

APP 3ID3

ID

APP 1ID1

APP 2ID2

APP 3ID3

eID & Datenschutz

Quelle: Prof. Posch, BKA


eID & eSigeID & eSig

2. Länderbeispiele



Trust Center derZertifizierungsdiensteanbieter (ZDA)

Register aus dem Öffentlichen Sektor

eID = ZDA* + öffentlichen Register

ZMRBMI

‚Elektronische Identität‘

* ZDA = Zertifizierungsdiensteanbieter

ZDAA-Trust ERnP

BMI


Stammzahl (SZ) Erzeugung (§ 6 Abs. 2 E-GovG)

ZMR-Zahl:

Verschlüsselung

Stammzahl

SZ = Verschlüsselte ZMR-Zahl

Stammzahlregisterbehörde errechnet die Stammzahl

SZ wird auf Karte geschrieben

Stammzahlregisterbehörde speichert die SZ NICHT (Virtuelles Register)

123456789012

Stammzahl: MDEyMzQ1Njc

http://www.a-trust.at/default.asp?node=352


bPK: Erzeugung

Stammzahl

Umrechnung unmöglich!

bPK a

z.B. Steuern & Abgaben z.B. Bauen & Wohnen

bPK b

nicht rückführbareAbleitung!

Quelle: BKA


eID & eSig im Verwaltungsverfahren

Duale Zustellung

Duale Zustellung

Fachanwendung / Backoffice

Fachanwendung / BackofficePortalPortal

z.B. HELP; Wien.gv.at

z.B. ELAK, Register (ZMR, GWR, Vollmachtsreg., Adressreg.),FinanzOnline u.a. Fachanwendungen z.B. zustellung.gv.at

Quelle: BKA


Bürgerkartenkonzept: Ausprägungen

eCard = SozialversicherungskarteMaestro BankomatkarteDienstausweise (Ministerien, Länder, ..)Schüler- & Studentenausweise

http://www.maestro.at/__C1256D6A0050E4B3.nsf/ie/810C3A9A33D0B11EC1256F6300306408?OpenDocument



BRD: eSig

Besonderheit der „Schriftform“ (§ 126 BGB)Elektronische Form (§ 126a Abs 1 )

"Soll die gesetzlich vorgeschriebene schriftliche Form durch dieelektronische Form ersetzt werden, so muss der Aussteller der Erklärung dieser seinen Namen hinzufügen und das elektronische Dokument mit einer qualifizierten elektronischen Signatur nach dem Signaturgesetz versehen."

Qualifizierte Signatur!


ePA: Elektronischer Personalausweis

3 Funktionen:

1. Identitätsfeststellung durch Polizei u.a. Behörden (= hoheitsrechtlich)

2. eID für Bürger & Wirtschaft (= privatrechtlich)

3. Optional elektronische Signatur


eID: Elektronischer Identifikationsnachweis

eID Funktionen für eGeschäfts- & Verwaltungsprozesse

eID Nachweis:Vorname(n), Familienname, (Akadem. Grad), Tag & Ort der Geburt,gegenwärtige Anschrift Max. Gültigkeitsdatum (ab 24.Lebensjahr 10 Jahre; für Jüngere 6 J.)"D" für BRDDokumentenart: Personalausweis kartenspezifische Kennzeichen

BürgerIn entscheidet welche Daten weitergegeben werden!



Niederlande: eID Modell

DigiD bietet zentrale Lösung (GBO.overheid.nl)

3 QualitätsstufenDigiD Basis: Username & PasswortDigiD Midden: Session-specific Login via SMSDigiD Hoog: ID-Card (geplant)

Output: eindeutige ID-Nummer!; keine weiteren Daten

basiert auf Verträgen - kein eigenes Gesetz!

DigiD High könnte mit Signaturgesetz verbunden werden


eSig



Malta: eID

3 Phasen:Phase 1: Username & Passwort zur IdentifizierungPhase 2: & ZertifikatePhase 3: Neue Personalausweise mit Zertifikaten

Phase 1 wurde umgesetztPhase 2 wird mit Business Kunden getestet

ABER: Zertifikate nur zur Identifizierung, nicht zum Signieren!



EU: Weitere Beispiele

Country Signature Detail / Other info

Belgium Qualified signature

Through mandatory eID card containing national register number. Qualified soft certificates from accredited CSPs are becoming secondary to the eID card.

Bulgaria Qualified certificate

Bulgaria Qualified certificate The so called ‘Universal Electronic Signature’, a soft certificate containing the Uniform Citizen Number.

Croatia Qualified certificate

Croatia Qualified certificate Software certificate from (one) accredited CSP

Cyprus Authentication Signature functionality is to some extent emulated through authentication procedures, but no real e- signature applications were identified.

Extrem heterogenes Umfeld – Länderspezifische Lösungen


eID & eSigeID & eSig3. Internationale Interoperabilität


App

licat

ion

Tier

Mid

dlew

are

Tier

Toke

n Ti

er

http://www.eid-stork.eu/

Europaweites eSig & eID Projekt: STORK

Quelle: BKA



Dr. Peter Parycek, MSc Zentrumsleiter E-GovernmentDonau-Universität Krems0043/2732/893 23120043/664/[email protected]

Webseiten: http://www.donau-uni.ac.at/egovhttp://www.slideshare.net/parycek/http://www.linkedin.com/in/peterparycek

ENDE

http://www.donau-uni.ac.at/egov

http://www.slideshare.net/parycek/

http://www.linkedin.com/in/peterparycek


Links

Studie zu eSig in Europa: http://ec.europa.eu/idabc/en/document/6485/5938/#activities

Studie zu eID in Europa:http://ec.europa.eu/information_society/activities/ict_psp/library/ref_docs/index_en.htm#eid

Aktuelle Projekte:eID: www.eid-stork.eu/eProcurement: www.peppol.eu/

Beispiele: www.epractice.eu/ ; www.digid.nl/

EU-Richtlinie: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML

www.digitales.oesterreich.gv.at

http://ec.europa.eu/idabc/en/document/6485/5938/#activities

http://ec.europa.eu/information_society/activities/ict_psp/library/ref_docs/index_en.htm#eid


http://www.peppol.eu/

http://www.epractice.eu/

http://www.digid.nl/

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML


Links Österreichisches E-Government

Standards: http://reference.e-government.gv.at/

Zentrales Bürgerportal: www.help.gv.at/

www.buergerkarte.at/

Zentrum für sichere Informationstechnologie: www.a-sit.at/

Datenschutzkommission: www.dsk.gv.at/

www.sozialversicherung.at/

Zertifizierungsdiensteanbieter: www.a-trust.at/

http://reference.e-government.gv.at/

http://www.help.gv.at/

http://www.buergerkarte.at/

http://www.a-sit.at/

http://www.dsk.gv.at/

http://www.sozialversicherung.at/

http://www.a-trust.at/


Recommendations

REC 01: Member States should be reminded of the letter and spirit of the public sector clause (art. 3.7), including their obligation in principle not to introduce requirements which constitute an obstacle to cross-border services for citizens; and of their notification obligations under article 11 of the Directive which require them to notify the Commission of any additional requirements imposed in application of article 3.7 insofar as these are a part of any voluntary accreditation scheme. Target group: Member StatesRECO2: Application owners should take note of signature solutions being used in other countries as identified by this study, and be made aware of their obligation in principle not to exclude foreign signature solutions whenever possible, unless specific considerations meeting the criteria of the public sector clause would permit this. Target group: eGovernment application ownerRECO3: Application owners should be advised to shift from the current situation of ad hoc decisions for each application, to a system where they require their users to employ a certain security/reliability level, such as the appropriate legal classification under the eSignatures Directive, rather than a specific certificate or CSP. Target group: eGovernment application ownerREC 04: Member States should be made conscious of the fact that their possible national decentralisation of competences does not absolve them of their obligations of adhering to the eSignatures Directive’s provisions, which includes the obligation of ensuring that local governments adhere to this framework. Target group: Member States


Recommendations

RECO5: Application owners should be made conscious of the interoperability consequences of requiring the use of identification attributes in signatures which are only available within their country. Target group: eGovernment application ownerRECO6: When determining the requirements for e-signature applications, application owners must ensure that the signature requirements are not abused to add functionality which is unrelated to the signature functionality itself when this would impair interoperability. There is no objection against using electronic signatures to add functionality (such as automatically filling out identity information or automated error correction) beyond the traditional functions of a handwritten signature (such as expression of consent, non-repudiation etc.); however, applications should not make such added functionality mandatory when this has the unintended side effect of making the use of foreign signature solutions impossible, unless an alternative can be offered to users whose signatures may not offer the added functionality. Target group: eGovernment application ownerRECO7 It is recommended that a pan-European signature certificate validation platform model is developed to resolve the issues of certificate validation and the issue of creating trust between existing CSPs. Such a platform would allow non-national PKI certificates to be validated in any country. Target group: Member States.


Recommendations

RECO8: Because of the internal market provisions of the Directive, the creation of pan-European validation platform should at a minimum be preceded by a consultation of the Member States on the main policy and legal issues arising as a result of the introduction of such a platform. Target group: European Commission and Member StatesRECO9: The unique number required by the application to identify the citizen/business should not be a mandatory part of the signature/certificate. Target group: eGovernment application ownerRECO10: Application owners should be recommended to make use of PKI-based signatures in applications where interoperability in the short term is a key objective Target group: eGovernment application ownerRECO11: Compliance with ETSI Qualified Certificate profile is recommended. Target group: eGovernment application ownerRECO12: The client signature tool should use standardized interfaces or applications that are de-facto available on any platform. Target group: eGovernment application owner RECO13: eGovernment applications that want to provide maximum interoperability within an open environment should rely on CSPs that do not impose any specific non-standardised interfaces. Target group: eGovernment application owner


Recommendations

RECO14: Promote the use of international standards (CAdES or XAdES) as eSignature formats. Target group: European Commission, Member States, International standardisation bodiesRECO15 New eGovernment applications should be encouraged to make use of PKI-based signatures if cross border interoperability is considered of Importance Target group: eGovernment application ownerRECO16 Publish, on a central website, a list of Certification Service Providers supervised43 by their respective national responsible body Target group: European CommissionRECO17 Implement the European IDA Bridge/Gateway CA (EBGCA) model that uses the centralised administrative structure of a bridge, and distributes trust using both cross-certifications and Certificate Trust Lists. Target group: European CommissionRECO18 The same legal concerns as voiced by RECO8 apply, and the same consultation of the Member States should be sought. Target group: European Commission; Member StatesRECO19 Set-up a pan-European ‘Validation Authority Federation’ Target group: European Commission; Member States