Benutzerspezifische Werkzeuge

Information zum Seitenaufbau und Sprungmarken fuer Screenreader-Benutzer: Ganz oben links auf jeder Seite befindet sich das Logo der JLU, verlinkt mit der Startseite. Neben dem Logo kann sich rechts daneben das Bannerbild anschließen. Rechts daneben kann sich ein weiteres Bild/Schriftzug befinden. Es folgt die Suche. Unterhalb dieser oberen Leiste schliesst sich die Hauptnavigation an. Unterhalb der Hauptnavigation befindet sich der Inhaltsbereich. Die Feinnavigation findet sich - sofern vorhanden - in der linken Spalte. In der rechten Spalte finden Sie ueblicherweise Kontaktdaten. Als Abschluss der Seite findet sich die Brotkrumennavigation und im Fussbereich Links zu Barrierefreiheit, Impressum, Hilfe und das Login fuer Redakteure. Barrierefreiheit JLU - Logo, Link zur Startseite der JLU-Gießen Direkt zur Navigation vertikale linke Navigationsleiste vor Sie sind hier Direkt zum Inhalt vor rechter Kolumne mit zusaetzlichen Informationen vor Suche vor Fußbereich mit Impressum


Artikelaktionen

Die Identnummer der JLU-Chipkarte

  1. Aufbau der Identnummer
  2. Ausgangssituation
  3. Anwendungen
  4. Eine globale, deutschland-weite Identnummer
  5. Die aktuellen Planungsansätze
  6. Die verwendeten Kennungen
  7. Zertifikatserstellung
Chipkarte-Matrikelnummer.jpg

JLU-Chipkarte, Vorderseite

1. Aufbau der Identnummer

Jede Chipkarte ist mit einer eindeutigen Identnummer verbunden. In Absprache mit den beteiligten Institutionen der Universität Gießen, dem Studentenwerk und dem Bibliotheksverbund in Hessen wurde eine hessen-einheitliche Form der Identnummer vereinbart. Sie steht an vier Stellen auf der Chipkarte

  • als 12-stellige Ziffernfolge lesbar auf der Kartenvorderseite
  • als Barcode "9 aus 39" auf der Kartenrückseite
  • im auslesbaren Speicher des kontaktbehafteten Mikrochips (MC1), sofern an dieser Stelle keine deutschland-weite Definition zum Einsatz kommt
  • verschlüsselt in einem Speicherfeld des kontaktlosen Mifare-Chips (MC2)

Wir sprechen im Folgenden von einer globalen (deutschland-weiten) bzw. einer lokalen (hier hessen-weiten) Kennung. Es wird zunächst die lokale Kennung beschrieben, die Beschreibung der globalen Nummer erfolgt im Abschnitt 4.

Die lokale Identnummer ist aus Ziffernblöcken mit festen Elementen aufgebaut.

Die Einzelelemente sind:

  • hk = lokale Hochschulkennung (zwei Ziffern)
  • kfnr = Kartenfolgenummer (eine Ziffer, 1 für die erste Kartenausgabe)
  • prz = Prüfzimmer (über die restlichen 11 Stellen, Verfahren nach Beutelspacher, s.u.)
  • gz = Gruppenzugehörigkeit (eine Ziffer), oft auch als Status bezeichnet
  • gnr = Matrikelnummer, Personalnummer, lfd. Gästenummer (immer 7 Ziffern, ggf rechts oder links mit Nullen aufgefüllt)

in der Anordnung hk-kfnr-prz-gz-gnr.

Die optische Darstellung auf der Kartenvorderseite erfolgt mit einem Bindestrich, beispielsweise 2617-11234567, intern wird die Kennung ohne die Bindestrich-Lesehilfe abgespeichert: 261711234567.

Beispiel 1 (Studierender an der Universität Gießen): 2617-11234567
26 : Hochschule "Universität Gießen"
1 : Kartenfolgenummer 1 (erste Karte)
7 : Prüfziffer (über die übrigen 11 Stellen)
1 : Studierende/r
1234567 : Matrikelnummer 1234567
Beispiel 2 (Mitarbeiter der Universität Gießen): 2624-20010667
26 : Hochschule "Universität Gießen"
2 : Kartenfolgenummer 2 (Ersatzkarte)
4 : Prüfziffer (über die übrigen 11 Stellen)
2 : Mitarbeiter/in
0010667 : Personalnummer 10667

2. Ausgangssituation

Die Personendaten wie Matrikel- und Personalnummern können nicht angepasst werden, sie sind zu übernehmen.

Vermieden werden sollte für die Chipkarte eine weitere, eindeutige neue Personenkennung zu erzeugen, um z.B. Matrikel- und Personalnummer nicht auf die Karten zu schreiben. Eine zusätzliche Tabellenabbildung bringt außer Fehlerquellen und Arbeitsaufwand keinen Nutzen. Die Kennung auf der Chipkarte stellt keine Veröffentlichung dar. Der Karteninhaber muss die Karte immer für sich behalten. Für eine Reihe von Situationen ist es sehr hilfreich, wenn der Betreffende seine Kennung bei sich trägt und sie angeben kann (z.B. Formular ausfüllen).

Es hat sich jedoch herausgestellt, dass die Matrikelnummer nur dann geheim gehalten werden kann, wenn Sie nicht im Zertifikat verwendet wird, so dass notwendigerweise noch eine weitere (eindeutige) Kennung für die Zertifikatsverwaltung erforderlich wird. Hierzu soll die eindeutige Prozessor-ID der Karte verwendet werden, siehe dazu Abschnitt 5.

Studentische und wissenschaftliche Hilfskräfte erhalten keinen Mitarbeiterausweis, sondern verwenden ihren Studienausweis, so lange sie noch immatrikuliert sind. Sollte es jedoch erforderlich sein, könnten durchaus einer Person zwei Karten (Studienausweis und Mitarbeiterausweis) ausgegebenen werden.

Matrikelnummern:
  • Universität Gießen: 7-stellig, mit Prüfziffer 8-stellig
  • FH Gießen-Friedberg: 6-stellig
  • FH Fulda: 6-stellig
Personalnummern:

Im Land Hessen werden von der Zentralen Vergütungs- und Lohnstelle (ZVL) landesweit eindeutige, 6-stellige Nummern vergeben. Die 7. Stelle wird als Überlauf bereitgehalten und ist derzeit noch 0. Bei der ZVL wird für eine Person auch bei meheren Arbeitsverträgen beim gleichen Arbeitgeber nur eine Personalnummer vergeben. Seit dem Jahr 2000 führen die hessischen Hochschulen hauseigene Personalnummern, von der Nummer 10000 an aufwärts. Es wird eine Nummer pro Arbeitsvertrag vergeben, es gibt aber einen Verweis auf die vorausgehenden Nummern. Die ZVL-Personalnummer wird als Dateneintrag mitgeführt, der Eintrag erfolgt aber oft erst viele Wochen später. Daher erscheint die 1. lokale SAP-Personalnummer eines Mitarbeiters die geeigneteste Grundlage für die Identnummer der Chipkarte zu sein, sie sollte rechtsbündig in den verfügbaren 7-stelligen Bereich eingetragen werden.

Bibliotheksnummern:

Im Bibliotheksverbund werden 12-stellige Endkunden-Nummern verwendet. Davon geben 4 Ziffern die eindeutige bundeseinheitliche Bibliotheksnummer an, die restlichen 8 Ziffern können von der Bibliothek vergeben werden.

Da die Bibliothek eine große Anzahl externer Benutzer in ihrem System verwaltet, wird ihr für diese Personengruppe die Gruppenzugehörigkeit "0" zugeteilt. Dies erlaubt ihr, die bisherigen Nummern für Externe weiterzuverwenden in einen modifizierten System, das die neuen Identnummern der Studenten und Mitarbeiter verwaltet.

Hochschulnummern:

Die HIS GmbH verwendet in ihrem System 4-stellige Hochschulnummern, die eine Hochschule eindeutig kennzeichnen. Diese Nummerierung ist nicht identisch mit der von den Bibliotheken verwendeten Nummerierung. Eventuell werden die bei HIS und anderen Institutionen verwendeten Hochschulkennungen in der globalen Identnummer verwendet.

Barcode:

Beim Barcode und vielen anderen Systemen ist eine maximale Ziffernzahl von 12 sinnvoll bzw. festgelegt.

Schlussfolgerungen:

Vorstehende Randbedingungen, sowie die Nebenbedingung, dass bei den Chipkarten die optisch lesbare Identnummer und die Identnummer im Mifare-Chip eine Prüfziffer bzw. eine Kartenfolgeziffer enthalten muss, haben zur Festlegung der folgenden, lokalen Identnummern-Struktur geführt. Die Prüfziffer ist wichtig, weil weiterhin der Mensch die verwendete Identnummer auf andere Systeme überträgt, z.B. ein Antragsformblatt oder einen Überweisungsträger ausfüllt, der später auch noch von einem Banken-Scanner gelesen wird, wobei jedesmal Fehler entstehen können, die von den verarbeitenden Systemen erkannt werden sollten. Aus diesen Randbedingungen ist folgende Identnummern-Struktur entstanden:

  • genau 12 Stellen lang
  • Stelle 1-2: (lokale, hessen-einheitliche) Hochschulkennung, 2-stellig
  • Stelle 3: Kartenfolgenummer
  • Stelle 4: Prüfziffer
  • Stelle 5: Gruppenzugehörigkeit/Status
  • Stelle 6-12: Personenkennung innerhalb der Gruppe (7 Stellen)

Als Nachteil ist hinzunehmen, dass die bisher an der Universität Gießen benutzte Matrikelnummernprüfziffer aufgegeben wird. An ihre Stelle tritt eine neue Prüfziffer, die sich auf die gesamte Identnummer bezieht (die Prüfziffer wird aus den 11 Stellen der lokalen Identnummer ohne Prüfziffer errechnet, das Verfahren wird weiter unten näher beschrieben).

3. Anwendungen

X.500-Verzeichnis

Die Identnummer wird voraussichtlich in zwei Attribute aufgenommen werden:

  • "employeeNumber" mit Gruppenzugehörigkeit+Personenkennung, also den letzten 8 Stellen der Identnummer
  • "cardID" mit der kompletten 12-stelligen Identnummer

Damit wird es möglich sein, sowohl allein mit der eindeutigen "employeeNumber" als auch mit der gesamten "cardID" eine Person eindeutig zu finden. Zur eindeutigen Erkennung reicht es also aus, nur die 8-stellige "employeeNumber" anzugeben.

Bibliotheken

Die Bibliotheken können die 8-stellige "employeeNumber" als alleinige Buchungsnummer verwenden, weil sie (lokal) eindeutig ist. Sie kann daher auch im Bibliotheksverbund direkt (ohne Abbildung auf eine Hilfskennung) verwendet werden.

Zahlungsvordrucke

Auf den Zahlungsvordrucken wird zukünftig statt einer 8-stelligen Matrikelnummer (einschl. Prüfziffer) die 12-stellige Identnummer verwendet. In ihr ist dann wieder eine Prüfziffer enthalten, die hilft, (Ab-)Schreibfehler oder Lesefehler bei den Banken zu entdecken und somit keine Fehlbuchung vorzunehmen. Will man die Banküberweisung durch die Bank sichern lassen (BZÜ), kann die 12-stellige Kennung direkt als sog. Kundenreferenznummer verwendet werden (diese kann maximal 12 Stellen umfassen, für die Bankprüfung wird eine 13. Stelle hinzugefügt).

4. Eine globale, deutschland-weite Identnummer

An meheren deutschen Hochschulen finden zur Zeit ähnliche Überlegungen bei der Einführung von Chipkarten statt. Einige regen dabei an, die Identnummer einer Karte so zu gestalten, dass eine Hochschul-Chipkarte auch an den anderen Hochschulen "verstanden" wird, sofern man einer allgemein verwendeten Struktur der Identnummer folgt. Mit anderen Worten, es sollte eine bundeseinheitliche (Teil-)Struktur der Identnummer geben, nicht nur eine, die nur an der eigenen Hochschule oder dem eigenen Bundesland "verstanden" wird. Einige wenige Hochschulen geben schon jetzt Karten bzw. Ausweise aus, die eine um die offizielle, amtliche Hochschulkennung erweiterte Matrikelnummer tragen.

In NRW sind m.W. schon Regelungen eingeführt worden, die die gegenseitige Anerkennung von Studienausweisen der Hochschulen untereinander betrifft. Dies ist generell anstrebenswert, weil es doch ziemlich oft Beziehungen eines Studenten zu einer anderen Hochschule gibt. Beispielsweise gewähren Hochschulrechenzentren den Studierenden einer anderen Hochschule in den meisten Fällen das Recht, von den Geräten der örtlichen Hochschule zum eigentlichen Hochschulort über das Wissenschaftsnetz zuzugreifen. Bisher wurde das im Allgemeinen mit gegenseitigen Bescheinigungen durch die Rechenzentren ermöglicht, diese Bescheinigungen waren für jede einzelne Person auszustellen und die Daten in lokale Dateien abzulegen.

Würde als Identnummer eine Kennung verwendet, aus der die jeweilige Hochschule eindeutig zu erkennen ist, könnte eine solche Karte automatisch erkannt und ihre Gültigkeit über das Zertifikat online geprüft werden. Es steht jeder Hochschule frei, Karteninhaber bestimmter fremder Hochschulen zuzulassen oder abzuweisen. Ist die verwendete Software darauf vorbereitet, auch fremde Karten zu lesen, sollte ein Zugangsversuch kein technisches Problem sein. Als minimales Ergebnis würde eine Fehlermeldung erzeugt, dass Chipkarten der Hochschule xyz hier nicht zugelassen sind.

Vorweg ist festzuhalten, dass hochschulübergreifende Anwendungen und Authentisierung nur über den kontaktbehafteten Chip sinnvoll sind. Der Zugriff auf verschlüsselte Mifare-Speicherdaten kann immer nur im lokalen Bereich erfolgen. Ferner wird für die Identifikation im Bereich des Mifare-Chips, Barcodes oder der äußerlich aufgedruckten Kartennummer eine Kartenfolgeziffer benötigt, damit bei Verlust eine neue Karte mit anderer Nummer ausgestellt wird und die alte Nummer für ungültig erklärt werden kann. Da die aufgedruckte Identnummer hin und wieder auf andere Datenträger (Formblätter, Überweisungsträger u.dgl.) übertragen werden muss, sollte sie möglichst handhabbar bleiben. Wir halten die vorgelegte Form aus 4+8 Stellen mit dem Bindestrich dazwischen als noch akzeptabel.

Bei einer PKI-basierten Kartenkennung im kontaktbehafteten Chip kann durchgehend auch mit Ersatzkarten eine einzige Kennung verwendet werden. Die Karte wird dadurch ungültig, dass das Zertifikat für ungültig erklärt wird. Bei einer neuen Karte kann durchaus die gleiche Kennung wiederverwendet werden, da es ja ein neues Schlüsselpaar gibt. Weiterhin kann auf die Prüfziffer in der Kartenkennung/Identnummer verzichtet werden, weil die Kennung im kontaktbehafteten Chip immer nur durch DV-Geräte und nicht von Menschen oder "unsicheren" Lesegräten ausgelesen und verarbeitet wird.

Leider wird durch die lokale Identifikation von Personen mit mindestens 8 Stellen, der Hochschulkennung mit 4 Stellen und weiterer Angaben, die Identnummer trotz ggf. fehlender Kartenfolgeziffer und Prüfziffer größer als 12 Stellen. Wir schlagen daher vor, bei der geplanten Chipkarte optisch und im Mifare-Chip mit der kompakten 12-stelligen, lokalen Identnummer zu arbeiten und für die Anwendungen mit dem kontaktbehafteten Chip die längere globale Identnummer durch die Software der Anwendungsverfahren benutzen zu lassen, von der der Kartenbesitzer im Allgemeinen nichts bemerkt.

Diese Art würde die Kartennutzung (mit der lokalen Identnummer) praktikabel halten und doch eine uneingeschränkte deutschland-weite Nutzung mit der globalen Identnummer ermöglichen.

Die Zusammensetzung einer solchen globalen Identnummer könnte beispielsweise wie folgt aussehen:

  • maximal 16 Stellen lang
  • Stelle 1-3: Landeskennung, 3-stellig (hier immer 262)
  • Stelle 4-7: amtliche Kennung der Hochschule, 4-stellig
  • Stelle 8: lokal, z.B. Kartenfolgenummer oder Gruppe
  • Stelle 9: lokal, z.B. Gruppenzugehörigkeit
  • Stelle 10-16: lokal, z.B. Personenkennung innerhalb der Gruppe (max. 7 Stellen)

Statt der 3-stelligen Landeskennung für Deutschland wäre auch eine 2-stellige Alpha-Kennung (DE) denkbar, wenn auch nicht numerische Zeichen in der Kennung erlaubt sein sollen.

Hier beispielhaft einige Hochschulnummern aus dem "Hochschulstatistik Gesetz":

1120 Universität Münster
1170, 1171, 1179 Universität Gießen (allgemein, ohne und mit Klinikum)
1180 Universität Marburg
6231 FH Gießen-Friedberg (Abtlg. Gießen)
6232 FH Gießen-Friedberg (Abtlg. Friedberg)
6290 FH Fulda

Es ist nicht empfehlenswert, eine Identnummer mit mehr als 16 Stellen zu verwenden, weil dies bei gewissen Anwendungen die Speicherkpazität sprengt.

Die hier vorgeschlagene Anordung hätte folgende Vorteile:

  • Die Landeskennung könnte welt- bzw. EU-weit verwendet werden. Hauptzweck ist aber vorerst, hiermit zu erkennen, dass die Identnummer der bundeseinheitlichen Absprache zur globalen Identnummer unterliegt und damit auf den folgen 4 Stellen die deutsche Hochschulkennung folgt.
  • Ab der 8. Stelle können alle Angaben hochschulspezifisch sein.
  • Wenn eine Hochschule mehr als 9 Gruppen verwenden möchte, könnte sie ggf. auf die Kartenfolgenummer in der Identnummer verzichten und die 8. und 9. Stelle zu einer 2-stelligen Gruppennummer zusammenfassen.
  • Analog könnte statt der maximal möglichen Personennummer von 7 Stellen eine von 8 Stellen Länge gebildet werden.

Dem Praktiker ist jedoch klar, dass eine 16-stellige Zahl von Menschen selbst nicht mehr ausreichend verlässlich gehandhabt werden kann. Oftmals haben bestehende Anwendungen auch engere Grenzen für ihre Benutzerkennungen. Als ein Beispiel sei hier das Bibliothekswesen genannt. Im deutschland-weiten Bibliotheksaustausch werden 12-stellige Nummern verwendet, 4 Ziffern geben die Bibliothek an, 8 Ziffern die lokale Benutzeridentifizierung. Im lokalen, hessen-weit eingesetzten PICA-System sind Kennungen bis 16 Stellen zulässig.

Sollte es zur Einführung einer globalen Identnummer kommen, werden wir die Chipkarte äußerlich mit der lokalen Identnummer versehen (lesbare Kennung und Barcode), wie im Abschnitt 1 beschrieben. Dafür gibt es im wesentlichen folgende Gründe:

  • Beim Ausfall der elektronischen Anwendung oder dort wo kein Chipkarten-Leser zur Verfügung steht, muss der Kartennutzer ggf. die lesbare Kennung angeben. Für diese Angabe sollte unbedingt eine Prüfziffer bereitstehen, um fehlerhafte Eingaben sofort oder später erkennen zu können.
  • Bei vielen bestehenden Anwendungen kann sich der Benutzer nur mit seiner lokalen Identnummer oder nur der Matrikel- bzw. Personalnummer anmelden, da keine langen Kennungen unterstützt werden.
  • Die Benutzer (Studierender, Mitarbeiter) sollte auf dem (Chipkarten-)Ausweis seine lokale Kennung (Matrikelnummer, Personalnummer) auf einfache Weise vorfinden, um z.B. Formulare oder Anfragen beantworten zu können.

Sachbearbeiter und Anwendungsprogramme können immer aus der lokalen Identnummer ohne Problem die globale Identnummer generieren (sofern sie in dem betreffenden Fall noch benötigt wird). Für den Karteninhaber ist es aber eher zumutbar und akzeptabel die kürzere, lokale Identnummer zu verwenden. "Verwenden" bedeutet in diesem Zusammenhang ja abschreiben, beispielsweise beim Ausfüllen eines speziellen Antrags, z.B. Exmatrikulation, einer Überweisung am Bankschalter oder am PC beim Homebanking. Nur wenn ein Chipkarten-Leser mit Anwendungsprogramm bereitstünde, würde er keine Angabe machen müssen, weil die Anwendung die Chipkarte auslesen würde.

Weil mehere Hochschulen zur Zeit die Einführung von Chipkarten mit elektronischer Signatur vorbereiten, müsste schnell ein Konsenz in dieser Sache hergestellt werden.

Aus den vorstehenden Angaben und weiteren Gedanken ist folgender Ansatz für die Gießener Chipkarten-Lösung in konkreter Planung bzw. Realisation.

5 Die aktuellen Planungsansätze

5.1 Die verwendeten Kennungen

Es wird in besonderem Maße der schon vorhandene X.500-Verzeichnisdienst berücksichtigt mit der nötigen Einbettung der für die Zertifikatsaufnahme erforderlichen Änderungen. Hierbei muss bedacht werden, dass X.500-Personeneinträge (angemeldeter) Benutzer öffentlich sind, wobei der Benutzer selbst entscheidet, welche Daten er öffentlich macht und welche er privat hält (die dann nur dem Systemdienst bzw. Systemmitarbeitern bekannt sind). Mit der Einführung der Chipkarten werden alle Benutzer bzw. Mitarbeiter in den Verzeichnisdienst aufgenommen werden müssen, um für alle Personen die Schlüsselzertifikate öffentlich bereitstellen zu können. Im Gegensatz zu den angemeldeten Personen, deren X.500-Eintrag sich in den durch die hierarchische Struktur vorgegebenen Unterorganisationen befindet, werden die Einträge von nicht-angemeldeten Personen in ein Sammelverzeichnis (ou=CIDs, certification ids) bzw. Unterverzeichnissen dazu aufgenommen. Das Zertifikat kann bei Kenntnis der anonymen Kennung gelesen, die Einträge insgesamt aber nicht durchsucht werden.

Für die angemeldeten Benutzer wird im Verzeichnis CIDs ein Alias-Eintrag abgelegt, für nicht angemeldete Studierende bzw. Mitarbeiter wird hier der volle X.500-Personeneintrag eingestellt. Der commonName dieses Eintrages sollte ursprünglich durch die o.g. Identnummer gebildet werden, beispielsweise in der Form cn=2621170-11234567. Aus ihr könnte entnommen werden das Land (262), die Hochschule (1170), sowie die lokal eindeutige Kennung Gruppe+interneKennung (z.B. Matrikel- oder Personalnummer). Der vollständige Pfad zum Auffinden dieses Zertifikates wäre dann:
"c=DE@o=Universität Giessen@ou=CIDS@cn=2621170-11234567".

Da die Pfadangabe einschließlich RDN auch im Zertifikat sichtbar ist und dieses öffentlich abrufbar ist, kann hier die Matrikelnummer nicht verwendet werden. Wir haben uns daher entschlossen, für die Zertifikatsverwaltung die Seriennummer des kontaktbehafteten Chipkarten-Prozessores zu verwenden. Diese Nummer ist eindeutig und anonym, sie gibt dem Zertifikat einen eindeutigen Namen. Das alternative Namensfeld des Zertifikats soll in Gießen den natürlichen Personennamen seines Besitzers enthalten. Im Gegensatz zu anderen Institutionen werden als alternativer Name weder der X.500-DN bzw. RDN verwendet noch die E-Mail-Adresse. Beide können sich ändern: es gibt Namensänderungen (ggf. auch Verlängerungen bei Namensgleichheit) sowie E-Mail-Adressen- oder X.500-DN-Änderungen durch Wechsel in einen anderen Bereich, die nicht notwendig eine neue Chipkarte erfordern.

Nur diejenigen Prozesse, die die Prozessor-ID lesen können, erhalten über die Nummer auch einen Lesezugriff auf das Zertifikat im Verzeichnisdienst. Es wird hingenommen, dass es möglich ist, aus einer Prozessor-ID auf andere Prozessor-Kennungen zu schließen (vorausgehende oder folgende Nummern). Da jedoch nur das Zertifikat aus dem Verzeichnisdienst gelesen werden kann, wird dem Abrufer über das Zertifikat nur der dort eingetragene Personenname bekannt (den er im Allgemeinen schon von der Chipkarten-Beschriftung kennt, wenn er sich unerlaubter Weise in den Besitz der Karte gebracht hat). Siehe dazu auch die Angaben zu Cert-ID. Man kann also nur sehr zufällig eine Beziehung Hochschule - Personenname herstellen. Weitere, insbesondere personenbezogene Daten stehen nicht zur Verfügung.

Die Prozessor-Seriennummer wird außer im commonName der Zertifikatsablage und im Zertifikat selbst nur noch in einer Datenbank der CA zusammen mit dem Public Key aufbewahrt, um damit Nachfolgezertifikate ausstellen zu können. Jeder commonName in ou=CIDs muss ein Zertifikat mit gleicher Angabe enthalten. Keine Person muss mit dem eindeutigen, langen Zertifikatsnamen (DN) umgehen, er wird lediglich zur prozessgesteuerten Zertifikatsverwaltung verwendet. Der Benutzer kann diese Prozessornummer jedoch in seinem Zertifikat finden; sie wird aber niemandem eine Hilfe sein (bspw. bei der Prüfung und Anzeige des Zertifikats in einem Programm). Deshalb enthält das alternative Namensfeld des Zertifikats den natürlichen Personennamen (der aber nicht notwendig eindeutig sein muss). Der Zertifikatsname (X.500-DN) ist über die Prozessor-Seriennummer eindeutig.

An der Universität Gießen werden mit den Chipkarten einschließlich Zertifikatsverwaltung voraussichtlich folgende Kennungen verwendet:

  • 1. Card-ID: 12-stellig, lokale Identnummer, z.B. "2617-11234567"
  • 2. Cert-ID: "2621170-processorID" oder "processorID"
  • 3. apn: vollständiger Personenname in ASCII-Schreibweise
  • 4. npn: vollständiger Personenname in nationaler Schreibweise
  • 5. spn: gekürzter Personenname in nationaler Schreibweise
  • 6. cn: X.500-commonName, gleichzeitig E-Mail-Angabe (ASCII)

1. Card-ID
Die Card-ID (lokale Identnummer) wird im X.500-Eintrag des Benutzers, angemeldeter und nicht angemeldeter Benutzer unter dem X.500-Attribut "cardID" aufgenommen. Der Eintrag/Wert ist öffentlich nicht sichtbar. Rechtsbündig ist die Matrikel- bzw. Personalnummer zu finden, sie wird immer 7-stellig geführt. Insgesamt 12 numerische Stellen, weitere Einzelheiten folgen weiter unten.

2. Cert-ID
Diese Angabe steht im X.509-Zertifikat als eindeutiger Zertifikatsname in der X.500-DN-Schreibweise, z.B.
"c=DE@o=Universitaet Giessen@ou=CIDs@ou=X@cn=processorID".
Der vordere Teil im cn gibt nochmals das Land und die Hochschule wieder. Im X.500-DIT wird unter dieser Adresse das X.509-Zertifikat abgelegt (nicht angemeldete Benutzer). Bei angemeldeten Benutzern steht an dieser Stelle ein Alias-Verweis auf den eigentlichen Personeneintrag. Zur technisch sinnvollen Unterteilung aller Personeneinträge der Datenbank wird das Zertifikat bzw. der Alias-Eintrag dazu in diejenige Untergruppe abgelegt, deren Name aus dem ersten Buchstaben des Familiennamens gebildet wird: Familienname=Meyerbrink-Lanz -> ou=M.

3. apn (Benutzername in ASCII-Schreibweise)
Diese Angabe wird zur Erleichterung und sicheren Umgang für den menschlichen Leser beim Alternativ-Namen in das Zertifikat aufgenommen. Um eventuellen Zeichensatzproblemen vorzubeugen, werden keine nationalen Zeichen zugelassen.

4. npn (vollständiger Benutzername in nationaler Schreibweise)
Er wird als commonName-Alias angemeldeter und nicht angemeldeter Benutzer eingetragen, bei ersteren ist er öffentlich sichtbar. Er kann auf Benutzerwunsch gekürzt werden. Sollte es zu Problemen bei der E-Mail-Adresswandlung mittels commonName-Search kommen, was selten ist, wird der vollständige Benutzername vom HRZ unter dem X.500-Attribut "fullname" abgelegt. Die Angabe npn ist nur für den menschlichen Leser vorgesehen.

5. spn (gekürzter Benutzername in nationaler Schreibweise)
Wie bei npn, wird als commonName-Alias verwendet, falls der vollständige Personenname nicht gewünscht wird, er störend ist oder zu technischen Schwierigkeiten führt.

6. cn (X.500-Recordname, commonName, lokaler Teil der E-Mail-Adresse)
Dieser Name wird nur aus ASCII-Zeichen gebildet, Umlaute werden als ae, oe, ue und ß als ss geschrieben. Die Namen werden grundsätzlich aus zwei oder drei Teilen zusammengesetzt:

  • Vorname (givenName, first name, ggf mit Bindestrichen, ohne Leerzeichen)
  • "Initial", "i": der erste Buchstabe vom 2. Vornamen (kann entfallen)
  • Nachname (surname, last name, ggf. mit Bindestrichen, ohne Leerzeichen)

Aus dem commonName wird die E-Mail-Adresse gebildet (Internet-Mailbox, preferredRfc822Recipient): "vorname.i.nachname@bereich.uni-giessen.de".

 

Im allg. entspricht der Maildomain "bereich" eine OU-Stufe im X.500-DIT. Sollte es dort zu Namensgleichheiten kommen, werden die Personennamen ohne "initial" um eine solche Angabe erweitert: Es wird dann der korrekte cn als commonName-Alias in beide X.500-Records eingetragen (z.B. Andreas Lange) und als Recordname jeweils "Andreas 1 Lange" bzw. "Andreas 2 Lange" benutzt. Wer dann Mail an "Andreas.Lange@bereich..." schickt, erhält eine Fehlermeldung mit einem Hinweis auf "Andreas.1.Lange" und "Andreas.2.Lange" zur Korrektur der verwendeten Adresse "Andreas.Lange@bereich...".

In der Card-ID (lokale Identnummer) sind die unter Abschnitt 1 beschriebenen Elemente vorhanden: lokale Hochschulkennung (2 Stellen), Kartenfolgenummer (1), Prüfziffer (1), Gruppe (1) und Kennung innerhalb der Gruppe (7), bspw. die Matrikel- oder Personalnummer. Die Card-ID wird im X.500 als Attribut "cardID" aufgenommen, ist jedoch nicht öffentlich lesbar.

In Hessen soll als Prüfzifferverfahren ein Vorschlag von Prof. Albrecht Beutelspacher verwendet werden, der auch bei den Seriennummern der D-Mark-Scheine in den 90er Jahren eingesetzt wurde. Das dem bei den ISBN-Code-Nummern in der Güte gleichkommende Verfahren hat den Vorteil, dass es mit den Prüfzeichen 0-9 auskommt. Beim ISBN wird auch noch X (10) benötigt. Das Verfahren ist im "Jahrbuch 1995, Überblicke Mathematik", Viewig, ISBN 3-528-06607-5 Pick It! , veröffentlicht. Eine Routine in C kann zur Verfügung gestellt werden, sie erzeugt bzw. prüft die Prüfziffer in der Standardschreibweise mit Prüfziffer hinten (dddddddddddp) oder in der Card-ID-Form dddp-dddddddd.

Bei der Neuausstellung einer Chipkarte ändert sich sowohl die Ablage des Zertifikats (X.500-DN) als auch lokale Identnummer/Card-ID aufgrund von Kartenfolge- und -prüfziffer. Das muss so sein, weil die Card-ID äußerlich und im Mifare-Chip nur aufgrund ihres Wertes verwendet wird. In diesem Fall muss der alte Wert in den eingesetzten Zugriffssystemen (z.B. Bibliothekskennung, Gebäudezugang) für ungültig erklärt werden und durch einen neuen ersetzt werden. Zur Sicherung des Zugangs mit dem kontaktbehafteten Chip und Zertifikatsprüfung auf Kartengültigkeit muss das alte Zertifikat "revoked" (in die "CRL" aufgenommen) werden.

Bei einer Rezertifizierung ändert sich der X.500-DN des Zertifikats und die globale bzw. lokale Identnummer nicht (bei der Veröffentlichung überschreibt das neue Zertifikat das alte).

In den oben gezeigten Beispielen für lokale Identnummer/Card-ID und Cert-ID wurde für den menschlichen Leser immer ein Bindestrich verwendet. Dieser kann auch so im Verzeichnisdienst, in und auf der Chipkarte verwendet werden (Ausnahme Barcode), um die Lesbarkeit zu erleichtern und mögliche Fehler durch menschliche Kontrolle zu ermöglichen. Der Bindestrich kann bei Bedarf auch weggelassen oder als zusätzliche Stelle eingeplant werden, wenn Kompatibilität erreicht werden soll oder mehr Nutzstellen benötigt werden.

Durch die Form der globalen Identnummer mit 262(Hochschulnummer)-(lokale id) bzw. Cert-ID mit cn=262(Hochschulnummer)-(anonyme id) könnte eine fremde Hochschule in die Lage versetzt werden, die Karte weiter zu interpretieren. Die Information 262 am Anfang könnte aussagen, hier handelt es sich (wahrscheinlich) um die Karte einer deutschen Hochschuleinrichtung, dessen Standardkürzel/Hochschulnummer auf den folgenden 4 Stellen zu finden ist. Wenn die Hochschule geneigt ist, könnte sie eine Zertifikatsprüfung vornehmen und ggf. allen oder gewissen Mitgliedern anderer Hochschulen die Nutzung von Zugängen bzw. Geräten gestatten, ganz ohne Verwaltungsaufwand für einen lokalen Zulassungsprozess.

5.2 Zertifikatserstellung

Siehe hierzu auch die Übersichtsskizze "Zertifikatserstellung und -erneuerung". Es wird auf die dort angeführten Ziffern verwiesen.

Ziffer (1) und (2): Die vom Hersteller gelieferten Chipkarten-Rohlinge werden zuerst im HRZ initialisiert, d.h. es werden

  • die Chipkarten-Prozessoren geprüft und die benötigten File-Strukturen erzeugt,
  • defekte Karten werden ausgesondert,
  • ein Schlüsselpaar erzeugt und beide Schlüssel auf der Karte abgelegt,
  • der öffentliche Schlüssel zusammen mit der/den Prozessornummer/n in einer lokalen Datenbank abgelegt,
  • sofort oder später beim X.500-Verzeichnisdienst ein Eintrag mit der Prozessornummer als commonName erzeugt: "c=DE@o=Uni....@ou=CIDs@cn=(hochschule)-prozessornummer"

Der Vorgang läuft im Batch-Betrieb ab bis die eingelegte Menge Kartenrohlinge bearbeitet ist. Die Karten werden anschließend gebündelt und der mit dem Initialisierungstag gekennzeichnete Stapel dem Studentensekretariat (RA) zur Verfügung gestellt.

Ziffer (3), (4) und (5):
Der Antrag auf Ausgabe einer Chipkarte wird durch Eingabe der entsprechenden Matrikelnummer vom Bedienungspersonal gestellt (die Eingabe kann ggf auch über Barcode erfolgen). Die benötigten Daten werden aus der HISSOS-DB abgerufen (4). Mit diesen Daten, der Prozessornummer und dem auf der Chipkarte vorhandenem öffentlichen Schlüssel wird der Request zur Ausstellung des Zertifikats an die CA gestellt (5). Die CA speichert das Zertifikat zu Prüfzwecken bei sich, trägt es beim X.500-Dienst im ggf. noch leeren Eintrag cn=(hochschulkennung)-prozessornummer ein und sendet es dem Personalisierungssystem zur Aufnahme in den Chipkarten-Speicher.

Ziffer (5) alternativ:
Die Daten zum Abruf eines Zertifikats können alternativ auch in eine Liste eingestellt werden, wenn keine Online-Verbindung zur CA verfügbar oder zugelassen ist. Über einen Datenträgeraustausch erhält die CA die Requests zur Zertifikatsausstellung und liefert die erstellten Zertifikate per Datenträgeraustausch auch wieder zurück.

Ziffer (6):
Nach der Komplettierung der Daten mit zufällig erzeugter PIN (ggf. auch PUK) kann die Karte "personalisiert" werden (Name, Bild, Card-ID, Barcode, Zertifikat usw.), die PIN und ggf. PUK werden zusammen mit dem Namen des Karteninhabers und seiner Card-ID ausgedruckt. Anschließend wird am 2. System die TRW-Folie der Karte beschrieben. Dazu identifiziert das TRW-Drucksystem die Karte aufgrund der Card-ID und ruft die Daten für die Folienbeschriftung ab: Gültigkeitszeitraum und RMV-Semesterticket, letzteres könnte je nach Einzelfall ggf. nicht gedruckt werden. Der Karteninhaber muss den Empfang von Chipkarte, PIN-Blatt und den Empfang ausführlicher datenschutzrechtlicher Hinweise persönlich quittieren. Der Chipkarten-Status in der HISSOS-Datenbank wird auf "Ausgabe Card-ID=x" gesetzt. Damit ist die Kartenerstellung und -ausgabe abgeschlossen.

Es ist vorstellbar, das der Karteninhaber selbst den Foliendruck veranlasst, damit er den bei der späteren Rückmeldung erforderlichen Vorgang des Foliendrucks kennenlernt.

Ziffer (7):
Zur Rückmeldung sucht der Karteninhaber einen PC mit Chipkarten-Leser auf, entweder an der Universität oder beliebig im Internet. Nach der Prüfung der verwendeten Chipkarte wird der Authentisierungs-Server dem Benutzer den Zugang zum HIS-Middleware-Server gewähren, damit er seine HISSOS-Daten kontrollieren und ggf. aktualisieren kann. Konnte die Rückmeldung abgeschlossen werden (ist bspw. Gebühreneingang erfolgt), erhält der Karteninhaber den Hinweis, sofort oder ab dem folgenden Tag an einem der TRW-Drucker auf dem Campusgelände die Chipkarte mit neuem Zertifikat und Gültigkeitsaufdruck aktualisieren zu lassen.

Auch außerhalb der Rückmeldung bietet der Authentisierungs-Server seine Dienste an, beispielsweise um das Zertifikat auf der Karte überprüfen zu lassen oder eine PIN-Änderung durchzuführen. Dabei akzeptiert der Server auch Chipkarten mit abgelaufenem Zertifikat, sofern ein neues Zertifikat im Verzeichnisdienst (ggf. verdeckt, d.h. noch nicht öffentlich) bereitsteht.

Ziffer (8):
Sobald die Voraussetzungen zu einer Zertifikatserneuerung gegeben sind (üblicherweise nach Eingang der Semestergebühren), werden in einem Hintergrundprozess von einen Server des HRZ (noch unbestimmt welcher), Requests für die Erstellung der neuen Zertifikate an die CA gegeben. Diese erstellt die neuen Zertifikate und legt sie verdeckt (nicht öffentlich) im Verzeichnisdienst ab, ggf. erfolgen die Zertifikatserstellungs-Requests und die Ausgabe bei der CA offline per Datenträger, wenn Sicherheitsaspekte dies erfordern sollten. Der hier beschriebene Vorgang (8) läuft im Normalfall vor der Aktivität (7) ab, dabei wird ein Zertifikat erzeugt (und im Verzeichnisdienst verdeckt abgelegt) aber noch nicht veröffentlicht. Mit dem explizitem Rückmeldevorgang (sofern vorgesehen), vgl. (7), oder der Chipkarten-Aktualisierung gemäß (9) wird erst das neue Zertifikat auf die Chipkarte übernommen und gleichzeitig öffentlich im Verzeichnisdienst bereitgestellt. Für die Umsetzung im Verzeichnisdienst haben der Authentisierungs-Server und die wenigen TRW-Drucksysteme eine entsprechende X.500-Authorisierung.

Ziffer (9):
Der Benutzer kann nach der expliziten oder impliziten Rückmeldung ein TRW-Drucksystem auf dem Universitätscampus aufsuchen, um insbesondere den Gültigkeitsaufdruck seiner Chipkarte aktualisieren zu lassen. Bei diesem Vorgang wird ggf noch das alte Zertifikat gegen das neue ausgetauscht. Wer sich nicht am Hochschulort aufhält (z.B. Auslandssemester, Arbeiten am Heimatort), kann in jedem Fall den Authentifizierungs-Server kontaktieren, um das Zertifikat auf der Chipkarte und im Verzeichnisdienst aktualisieren zu lassen. Auf die optische Aktualisierung der Kartengültigkeit muss er dabei aber verzichten.

Ziffer (10):
Sollte es nötig werden, die Chipkarte sperren zu lassen, steht dafür die HRZ-Hotline (z.Zt. Mo--Fr, 6--21 h) oder über ein Web-Dokument gesperrt. Ohne Sperr-Code-Angabe muss ein schriftlicher Antrag vorgelegt werden. Es kann eine "temporäre Sperre" veranlasst werden, die alle lokalen Zugänge wirksam sperrt (Benutzer-Accounts, Bibliotheks- und Gebäudezugang, HISSOS-Zugriff und dergleichen), aber keinen (immer endgültigen) Eintrag in der Certificate Revocation List (CRL) erzeugt. Dies hat den Vorteil, dass keine teure und aufwändige Kartenneuausstellung erforderlich wird, wenn die Karte nicht wirklich abhanden kam, sondern wieder auftaucht. Die temporäre Sperre ist auf maximal 7 Tage begrenzt. Intern wird die temporäre Sperre erreicht durch "Löschen" des Zertifikats aus dem Verzeichnisdienst. Daher müssen lokale Zugriffsdienste ggf. immer das Zertifikat aus dem Verzeichnisdienst abrufen, wenn die Sperre nicht mit anderen Vorkehrungen erfolgt, wie das für die Rechnerzugänge, Bibliotheks- und Gebäudezugang geplant ist. In diesen Fällen ist die temporäre Sperre in der Wirkung der permanenten Sperre gleichzusetzen. Dienste, die die Sperre über die CRL überprüfen (etwa Mail-Signierung und Verschlüsselung) werden von der temporären Sperre im Normalfall nicht beeinflusst.

Nach 7 Tagen wird eine temporäre Sperre automatisch in eine permanente Sperre übergeleitet. Vor dem Ablauf der 7-Tage-Frist kann eine temporäre Sperre mit der "wiedergefundenen" Chipkarte wieder aufgehoben werden über den Authentisierungs-Server. Dabei werden die lokalen Zugangssperren mit einer organisatorisch-technischen Verzögerung von mindestens einem Werktag aufgehoben. Eine endgültige Sperre mit Aufnahme des Zertifikats in die Revocation-Liste (CRL) kann nicht mehr rückgängig gemacht werden, d.h. der Karteninhaber muss persönlich die Hochschule aufsuchen und sich gegen Kostenerstattung eine neue Chipkarte ausstellen lassen.

Schlussbemerkungen:
(1) Das hier geschilderte Vorgehen erlaubt, neue Zertifikate herzustellen (etwa nach Eingang der Semestergebühren) und nicht öffentlich bereitzustellen. Erst wenn der Kartenbesitzer die Karte aktualisiert (bewusst oder unbewusst), wird das neue Zertifikat auf die Chipkarte übertragen und gleichzeitig im Verzeichnisdienst freigegeben. (a) Der Studierende erhält sein neues Zertifikat im Allgemeinen ohne Verzögerung beim ersten Kontakt mit dem Server, (b) die CA könnte offline betrieben werden, wenn die Sicherheit dies erfordern sollte und (c) der Betreiber hat nur relativ wenige Zertifikate in die CRL aufzunehmen, wenn die verdeckten Zertifikate nicht "abgeholt" worden sind, weil der Studierende sich doch noch zur Exmatrikulation entschlossen hat.

(2) Mit der temporären Sperre soll die Sicherheit und der Benutzerservice erhöht werden, in dem Benutzer eine verlorene Chipkarte schnell sperren (lassen), weil sie keine Angst vor Aufwand und Kosten einer Kartenneuausstellung haben müssen für den Fall, die Karte wurde nur verlegt. Durch Automatisierung des Verfahrens bei der Sperre kann der organisatorische Aufwand in Grenzen gehalten werden. Durch die verzögerte Freigabe nach einer temporären Sperre, wird dem Missbrauch vorgebeugt, ohne den Benutzer im Vorfeld von der Sperre abzuhalten.