W2014-ITS: Difference between revisions
m (Created page with "=Themenvorschläge für IT-Security Workshop 22. September bis 2. Oktober [https://sar.informatik.hu-berlin.de/teaching/2014-w/2014-w%20IT%20Security%20Workshop/ 2014]= ==Selbst…") |
m (→Vorträge) |
||
| (36 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
=Vorträge= |
|||
=Themenvorschläge für IT-Security Workshop 22. September bis 2. Oktober [https://sar.informatik.hu-berlin.de/teaching/2014-w/2014-w%20IT%20Security%20Workshop/ 2014]= |
|||
'''Donnerstag 2.10. 2014,''' Rudower Chaussee 25, Haus 3, '''Raum 3'328''' |
|||
==Selbstauskunft "in-the-middle"== |
|||
Nach der reinen Lehre über die Nutzung des neuen Personalausweises muss jeder (Dienstanbieter) der Datengruppen bzw. Funktionen aus dem nPA mit Hilfe der eID-Funktion nutzen will, ein gültiges Berechtigungszertifikat von der [http://www.bva.bund.de/cln_351/DE/Aufgaben/Abt__III/nPA/Vergabestelle/node.html?__nnn=true Vergabestelle] vorweisen und einen eID-Server betreiben (oder den entsprechenden eID-Service anmieten). Das ist sicher etwas aufwändig. Geht es nicht etwas einfacher? Wenn man sich an der Lösung Sofortüberweisung orientiert, so könnte man auf die Idee kommen, einem Nutzer mittels "man-in-the-middle" quasi dabei über die Schulter zu schauen, wie er eine Onlineauthentisierung gegenüber einem Dienstanbieter mit Berechtigungszertifikat durchführt. |
|||
{| class="wikitable" style="text-align: left; background: #eee;" |
|||
Schreiben Sie eine App, die eine Piggyback-Authentisierung via den vom Bürgerportal der Stadt Würzburg angebotenen Dienst zur Selbstauskunft nutzt. |
|||
|- style="background: #efe;" |
|||
Das Lesegerät für den nPA soll über Bluetooth mit dem nPA verbunden werden und der Leser soll eine eigenen PIN-Eingabe und Anzeige der Transaktion ermöglichen. |
|||
| 09:30-10:30 || '''Eigener Sync-Server für Firefox''' || Maximilian, Tom|| |
|||
|- |
|||
| 10.30-11:30 || '''Verteilte Erkennung von fehlgeschlagenen SSH-Loginversuchen ''' || Phillipp, Dirk || |
|||
[https://sar.informatik.hu-berlin.de/teaching/2014-w/2014w_ITSecurityWorkshop/talks/SSH%20Attack%20Detection_Dokumentation.pdf pdf] |
|||
|- style="background: #fee;" |
|||
| 11:30-12:30 || '''Mittagspause''' || || |
|||
|- style="background: #efe;" |
|||
| 12:30-13:30 || '''DANE für unseren Mail-Server''' || Christoph, Sven || [https://sar.informatik.hu-berlin.de/teaching/2014-w/2014w_ITSecurityWorkshop/talks/DNSSEC_DANE_.pdf pdf] |
|||
|- |
|||
| 13:30-14:30 || '''U2F FIDO''' || Oliver, Marc || |
|||
[https://sar.informatik.hu-berlin.de/teaching/2014-w/2014w_ITSecurityWorkshop/talks/Gnubby_Overview_.pdf pdf] |
|||
|- |
|||
|} |
|||
Pro Gruppe ist angedacht, die 60 min auf 45 min Vortrag (+ ggf. Demo) und 15 min Diskussion und Umbaupause aufzuteilen. |
|||
=Themenvorschläge für [https://sar.informatik.hu-berlin.de/teaching/2014-w/2014w_ITSecurityWorkshop/ IT-Security Workshop] 22. September bis 2. Oktober [https://sar.informatik.hu-berlin.de/teaching/2014-w/2014w_ITSecurityWorkshop/ 2014]= |
|||
==[https://sarwiki.informatik.hu-berlin.de/Eigener_Sync-Server_f%C3%BCr_Firefox Eigener Sync-Server für Firefox] (Maximilian, Tom)== |
|||
Die Authentisierung mittels (Name,Passwort) wird nach wie vor von vielen Diensten im Internet verwendet. Der Nutzer ist bei der Vielzahl der Dienste schlichtweg überfordert, sich all diese zu merken. Als Konsequenz wurden Lösungen wie Single Sign On oder Open ID vorgeschlagen. In der post-Snowden-Ära gibt es jedoch Bedenken, die Authentisierung an eine dritte Partei auszulagern, da diese auch im Namen des legitimen Nutzers ohne diesen eine erfolgreiche Authenisierung bewerkstelligen könnte. |
|||
Einen anderen Ansatz bieten Passwortmanager. Hier wird dem Benutzer angeboten, mit Hilfe (eines hoffentlich starken Masterpassworts) den Zugang zu den Authentisierungsdaten für die einzelnen Dienste abzusichern. Die Referenzdaten dazu können beispielsweise lokal verschlüsselt gespeichert werden. Allerdings ist es ggf. wünschenswert den Passwortmanager auch auf verschiedenen Geräten nutzen zu können. Eine Lösung die auch die Synchronisierung zwischen verschiedenen Geräten vorsieht, ist Firefox Sync" was auch direkt im Firefox ohne zusätzliche Plugins oder Erweiterungen nutzbar ist. |
|||
Jedoch werden die (zwar verschlüsselten) Referenzdaten auf einem zentralen Server gespeichert. Hier wäre es wünschenswert, eine Lösung umzusetzen, die eine Speicherung auf Ihrem eigenen Server zulässt. |
|||
Links: |
Links: |
||
* [https://docs.services.mozilla.com/howtos/run-sync-1.5.html Run your own Sync-1.5 Server] |
|||
* [https://www.buergerserviceportal.de/bayern/wuerzburg/bspx_selbstauskunft Selbstauskunft] |
|||
* [https://docs.services.mozilla.com/howtos/run-fxa.html Run your own Firefox Accounts Server] |
|||
* [https://www.sofort.com/ger-DE/sicherheit/ Sofortüberweisung] |
|||
* [http://devd.me/papers/pwdmgr-usenix14.pdf The Emperor’s New Password Manager: Security Analysis of Web-based Password Managers] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==[[U2F FIDO]] (Oliver, Marc)== |
|||
Zunehmend werden schwache Nutzerpassworte bei Webdiensten zum Problem. Die Nutzer sehen sich mit einer wachsenden Zahl von für ihr tägliches Leben bedeutungsvollen Webdiensten konfrontiert, für die sie eine sichere und individuelle Authentisierung benötigen. Die von Google vorgeschlagene Idee eines "universal second factor" U2F addressiert genau dieses Problem. Die Authentisierung verwendet einen universellen Hardwaretoken "Gnubby" der über USB, NFC später vielleicht auch über Bluetooth 4.0 an ein IT-System angebunden wird und einen Smardcardchip beinhaltet. |
|||
Untersuchen Sie dieses System, finden Sie heraus, wie es arbeitet und ob ein pseudonymes Login damit realisierbar ist. |
|||
U2F wird als Beitrag zu einem größeren Vorhaben der FIDO-Alliance gesehen |
|||
Links: |
|||
* [https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-ozN6j3-fr7JL8XVyA/edit?pli=1#slide=id.g19c09a112_2_0 Slides] |
|||
* [https://u2fdemo.appspot.com/ Testdienst] |
|||
* [https://github.com/google/u2f-ref-code Code] |
|||
* [https://fidoalliance.org/ FIDO] |
|||
* [http://fidoalliance.org/specs/fido-u2f-raw-message-formats-v1.0-rd-20140209.pdf FIDO U2F Raw Message Formats] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==Smartcards und Dämone virtuell== |
|||
Für die Ein- oder Anbindung von Smartcards an IT-Systeme bestehen weitreichende Standards. Aus Sicht eines Betriebsystems oder Klienten, der darauf zugreift ist eine Smartcard nicht als solche erkennbar, insbesondere ist es nicht erforderlich, dass es sich um eine physische Karte handelt, oder dass diese sich wirklich räumlich in der Nähe zu dem verwendeten IT-System befindet. Hierraus ergeben sich diverse spannende Möglichkeiten zur Emulation oder Weiterleitung von Smartcards oder deren virtuellen Entsprechungen. |
|||
==Absicherung NFS== |
|||
====vpcd für Windows (eventuell Kopplung an entfernten Reader)==== |
|||
Bei NFS-Freigaben sind hohe Anforderungen an die Integrität des NFS-Clienten gestellt, da allein dieser über die Einhaltung der im exportierten Dateisystem gesetzten Rechte entscheidet. Daher ist es es essentiell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Addresse, die in der /etc/exports angegeben ist. |
|||
Einen Dämon der virtuelle oder auch echte Smartcards an ein System anbindet vpcd ist für Linux in den Grundzügen auf unter Windows und schon vorhanden. Ihre Aufgabe wäre es,diesen konsequent nach Windows zu portieren, und damit im Idealfall eine Einbindung eines entfernten Lesers an ein Windowssystem zu ermöglichen. |
|||
Untersuchen Sie, welche Verbesserungen hier möglich sind und welchen Aufwand, welche Komplexität die von Ihnen erarbeitenden Lösungen haben. Die verlässlichere Prüfung könnte auf verschiedenen Schichten angesetzt werden. |
|||
====PKCS#15-Implementierung für vicc==== |
|||
Für das Framework zum erstellen von virtuellen Smartcards vicc wäre es sehr nützlich auch die Funktionalität von PKCS#15 bereitzustellen. |
|||
Links: |
Links: |
||
* [https://de.wikipedia.org/wiki/IEEE_802.1X 802.1X] |
|||
* [http://vsmartcard.sourceforge.net/ Virtual Smartcard] |
|||
* [https://www.stunnel.org/index.html stunnel] |
|||
* [http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-15-cryptographic-token-information-format.htm PKCS#1] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell] |
|||
==[[DANE für unseren Mail-Server]] (Christoph, Sven)== |
|||
Die im RFC 6698 beschriebene "DNS-Based Authentication of Named Entities (DANE)" scheint ein gutes Mittel zu sein, um jenseits von bestehenden PKI-Mechanismen eine starke Authentisierung eines Servers und spätere Absicherung der Verbindung über SSL/TLS ausgehend von dessen DNS-Namen zu erreichen. Versuchen Sie dieses Konzept für unseren Institutsmailserver umzusetzen. |
|||
Links: |
|||
* [http://www.heise.de/ct/heft/2014-11-DANE-verbessert-sicheren-Transport-zwischen-Mailservern-2228494.html C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern] |
|||
* [http://tools.ietf.org/html/rfc6698 RFC 6698 DANE] |
|||
* [http://www.ietf.org/rfc/rfc4033.txt RFC 4033 DNSsec] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==[[Verteilte Erkennung von fehlgeschlagenen SSH-Loginversuchen]] (Phillipp, Dirk)== |
|||
Derzeit werden fehlgeschlagene Loginversuche über SSH auf unseren Institutsrechnern in lokalen Logfiles mitprotokolliert. Erfolgen von einer Absender IP auf einem Rechner zu viele davon, so wird angenommen, dass es sich um einen Angriff handelt und der Zugriff von dieser IP wird für eine gewisse Zeit gesperrt. Wünschenswert wäre eine schnellere Erkennung von Angriffen, die parallel mehrere unserer Rechner zum Ziel haben. |
|||
Entwickeln Sie ein Konzept für eine verteilte Erkennung und Sperrung! |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell] |
|||
==Smartcards@SUNray== |
|||
Wie Sie ja vielleicht schon bemerkt haben, kann man gewisse Smartcards zur Identifizierung einer bestehenden Session auf einem SUNray nutzen und diese dann später wieder an einem anderen Terminal (oder auch dem gleichen) auf den Schirm holen (keine Sorge, Nutzername/Passwort werden noch zum Login benötigt). Dies funktioniert mit gewissen Kartentypen (Siehe condor:/etc/opt/SUNWut/smartcard) . Versuchen Sie zusätzliche Konfigurationsfiles zu schreiben, die in Deutschland verbreitete kontaktbehaftete Smartkarten (eGK, EC-Card) zu diesem Zweck nutzen. |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==Selbstauskunft "in-the-middle"== |
|||
Nach der reinen Lehre über die Nutzung des neuen Personalausweises muss jeder (Dienstanbieter) der Datengruppen bzw. Funktionen aus dem nPA mit Hilfe der eID-Funktion nutzen will, ein gültiges Berechtigungszertifikat von der [http://www.bva.bund.de/cln_351/DE/Aufgaben/Abt__III/nPA/Vergabestelle/node.html?__nnn=true Vergabestelle] vorweisen und einen eID-Server betreiben (oder den entsprechenden eID-Service anmieten). Das ist sicher etwas aufwändig. Geht es nicht etwas einfacher? Wenn man sich an der Lösung Sofortüberweisung orientiert, so könnte man auf die Idee kommen, einem Nutzer mittels "man-in-the-middle" quasi dabei über die Schulter zu schauen, wie er eine Onlineauthentisierung gegenüber einem Dienstanbieter mit Berechtigungszertifikat durchführt. |
|||
Schreiben Sie eine App, die eine Piggyback-Authentisierung via den vom Bürgerportal der Stadt Würzburg angebotenen Dienst zur Selbstauskunft nutzt. |
|||
Das Lesegerät für den nPA soll über Bluetooth mit dem nPA verbunden werden und der Leser soll eine eigenen PIN-Eingabe und Anzeige der Transaktion ermöglichen. |
|||
Links: |
|||
* [https://www.buergerserviceportal.de/bayern/wuerzburg/bspx_selbstauskunft Selbstauskunft] |
|||
* [https://www.sofort.com/ger-DE/sicherheit/ Sofortüberweisung] |
|||
Mentor: |
|||
==Rund um den eIDClientCore== |
==Rund um den eIDClientCore== |
||
| Line 37: | Line 108: | ||
Mentor: |
Mentor: |
||
==RSA-PSK Unterstützung für mod_ssl== |
==RSA-PSK Unterstützung für mod_ssl== |
||
| Line 44: | Line 116: | ||
Mentor: |
Mentor: |
||
== Pseudonyme Signaturen mit dem nPA=== |
|||
== Pseudonyme Signaturen mit dem nPA== |
|||
In dem Paper "Domain-Specific Pseudonymous Signatures for the German Identity Card" wird ein Vorschlag gemacht, wie pseudonyme Signaturen dem (zukünftigen nPA) gemacht werden können. Das ermöglicht Signaturen mit dem nPA die nicht als QES angesehen werden, sondern eher zur Bestätigung oder Auslösung von Transaktionen genutzt werden können. Lesen und verstehen Sie die Ideen. Implementieren Sie dieses Protokoll, indealer Weise in OpenPACE. |
In dem Paper "Domain-Specific Pseudonymous Signatures for the German Identity Card" wird ein Vorschlag gemacht, wie pseudonyme Signaturen dem (zukünftigen nPA) gemacht werden können. Das ermöglicht Signaturen mit dem nPA die nicht als QES angesehen werden, sondern eher zur Bestätigung oder Auslösung von Transaktionen genutzt werden können. Lesen und verstehen Sie die Ideen. Implementieren Sie dieses Protokoll, indealer Weise in OpenPACE. |
||
| Line 51: | Line 124: | ||
Mentor: |
Mentor: |
||
==Sichere Wiki-Konfiguration / Migration (Alexander)== |
|||
Ein Wiki ist seiner Natur nach ein offenes System, in welchem der "Mitmachgedanke" weit vorne steht. Leider gibt es dann doch häufig automatisierte Angriffe, die diese Eigenschaft ausnutzen. So fand sich auch in unserm Wiki viel SPAM. |
|||
Versuchen Sie eine Kopie unseres Wikis auf eine aktuelle Codebasis zu heben. Dokumentieren Sie Ihre einzelnen Schritte. Treffen Sie eine begründete Auswahl an Zusatzpaketen zur Integration von Formeln, Bildern, ... und versuchen Sie eine möglichst sichere Konfiguration zu erreichen. Ansatzpunkte könnten die Verwendung von Captchas, sowie Beschränkungen zum anlegen von Nutzeraccounts sein. |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://sar.informatik.hu-berlin.de/people/wolfgang_gandre.htm Wolfgang Gandre] |
|||
==UEFI Secure Boot== |
==UEFI Secure Boot== |
||
| Line 64: | Line 146: | ||
* http://ho.ax/De_Mysteriis_Dom_Jobsivs_-_Syscan.pdf |
* http://ho.ax/De_Mysteriis_Dom_Jobsivs_-_Syscan.pdf |
||
Mentor: |
Mentor: |
||
==AeroFS überwachen== |
==AeroFS überwachen== |
||
Latest revision as of 12:26, 16 October 2014
Vorträge
Donnerstag 2.10. 2014, Rudower Chaussee 25, Haus 3, Raum 3'328
| 09:30-10:30 | Eigener Sync-Server für Firefox | Maximilian, Tom | |
| 10.30-11:30 | Verteilte Erkennung von fehlgeschlagenen SSH-Loginversuchen | Phillipp, Dirk | |
| 11:30-12:30 | Mittagspause | ||
| 12:30-13:30 | DANE für unseren Mail-Server | Christoph, Sven | |
| 13:30-14:30 | U2F FIDO | Oliver, Marc |
Pro Gruppe ist angedacht, die 60 min auf 45 min Vortrag (+ ggf. Demo) und 15 min Diskussion und Umbaupause aufzuteilen.
Themenvorschläge für IT-Security Workshop 22. September bis 2. Oktober 2014
Eigener Sync-Server für Firefox (Maximilian, Tom)
Die Authentisierung mittels (Name,Passwort) wird nach wie vor von vielen Diensten im Internet verwendet. Der Nutzer ist bei der Vielzahl der Dienste schlichtweg überfordert, sich all diese zu merken. Als Konsequenz wurden Lösungen wie Single Sign On oder Open ID vorgeschlagen. In der post-Snowden-Ära gibt es jedoch Bedenken, die Authentisierung an eine dritte Partei auszulagern, da diese auch im Namen des legitimen Nutzers ohne diesen eine erfolgreiche Authenisierung bewerkstelligen könnte.
Einen anderen Ansatz bieten Passwortmanager. Hier wird dem Benutzer angeboten, mit Hilfe (eines hoffentlich starken Masterpassworts) den Zugang zu den Authentisierungsdaten für die einzelnen Dienste abzusichern. Die Referenzdaten dazu können beispielsweise lokal verschlüsselt gespeichert werden. Allerdings ist es ggf. wünschenswert den Passwortmanager auch auf verschiedenen Geräten nutzen zu können. Eine Lösung die auch die Synchronisierung zwischen verschiedenen Geräten vorsieht, ist Firefox Sync" was auch direkt im Firefox ohne zusätzliche Plugins oder Erweiterungen nutzbar ist.
Jedoch werden die (zwar verschlüsselten) Referenzdaten auf einem zentralen Server gespeichert. Hier wäre es wünschenswert, eine Lösung umzusetzen, die eine Speicherung auf Ihrem eigenen Server zulässt.
Links:
- Run your own Sync-1.5 Server
- Run your own Firefox Accounts Server
- The Emperor’s New Password Manager: Security Analysis of Web-based Password Managers
Mentor: Wolf Müller
U2F FIDO (Oliver, Marc)
Zunehmend werden schwache Nutzerpassworte bei Webdiensten zum Problem. Die Nutzer sehen sich mit einer wachsenden Zahl von für ihr tägliches Leben bedeutungsvollen Webdiensten konfrontiert, für die sie eine sichere und individuelle Authentisierung benötigen. Die von Google vorgeschlagene Idee eines "universal second factor" U2F addressiert genau dieses Problem. Die Authentisierung verwendet einen universellen Hardwaretoken "Gnubby" der über USB, NFC später vielleicht auch über Bluetooth 4.0 an ein IT-System angebunden wird und einen Smardcardchip beinhaltet. Untersuchen Sie dieses System, finden Sie heraus, wie es arbeitet und ob ein pseudonymes Login damit realisierbar ist. U2F wird als Beitrag zu einem größeren Vorhaben der FIDO-Alliance gesehen
Links:
Mentor: Wolf Müller
Absicherung NFS
Bei NFS-Freigaben sind hohe Anforderungen an die Integrität des NFS-Clienten gestellt, da allein dieser über die Einhaltung der im exportierten Dateisystem gesetzten Rechte entscheidet. Daher ist es es essentiell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Addresse, die in der /etc/exports angegeben ist.
Untersuchen Sie, welche Verbesserungen hier möglich sind und welchen Aufwand, welche Komplexität die von Ihnen erarbeitenden Lösungen haben. Die verlässlichere Prüfung könnte auf verschiedenen Schichten angesetzt werden.
Links:
Mentor: Jan-Peter Bell
DANE für unseren Mail-Server (Christoph, Sven)
Die im RFC 6698 beschriebene "DNS-Based Authentication of Named Entities (DANE)" scheint ein gutes Mittel zu sein, um jenseits von bestehenden PKI-Mechanismen eine starke Authentisierung eines Servers und spätere Absicherung der Verbindung über SSL/TLS ausgehend von dessen DNS-Namen zu erreichen. Versuchen Sie dieses Konzept für unseren Institutsmailserver umzusetzen.
Links:
- C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern
- RFC 6698 DANE
- RFC 4033 DNSsec
Mentor: Jan-Peter Bell, Wolf Müller
Verteilte Erkennung von fehlgeschlagenen SSH-Loginversuchen (Phillipp, Dirk)
Derzeit werden fehlgeschlagene Loginversuche über SSH auf unseren Institutsrechnern in lokalen Logfiles mitprotokolliert. Erfolgen von einer Absender IP auf einem Rechner zu viele davon, so wird angenommen, dass es sich um einen Angriff handelt und der Zugriff von dieser IP wird für eine gewisse Zeit gesperrt. Wünschenswert wäre eine schnellere Erkennung von Angriffen, die parallel mehrere unserer Rechner zum Ziel haben.
Entwickeln Sie ein Konzept für eine verteilte Erkennung und Sperrung!
Mentor: Jan-Peter Bell
Smartcards@SUNray
Wie Sie ja vielleicht schon bemerkt haben, kann man gewisse Smartcards zur Identifizierung einer bestehenden Session auf einem SUNray nutzen und diese dann später wieder an einem anderen Terminal (oder auch dem gleichen) auf den Schirm holen (keine Sorge, Nutzername/Passwort werden noch zum Login benötigt). Dies funktioniert mit gewissen Kartentypen (Siehe condor:/etc/opt/SUNWut/smartcard) . Versuchen Sie zusätzliche Konfigurationsfiles zu schreiben, die in Deutschland verbreitete kontaktbehaftete Smartkarten (eGK, EC-Card) zu diesem Zweck nutzen.
Mentor: Jan-Peter Bell, Wolf Müller
Selbstauskunft "in-the-middle"
Nach der reinen Lehre über die Nutzung des neuen Personalausweises muss jeder (Dienstanbieter) der Datengruppen bzw. Funktionen aus dem nPA mit Hilfe der eID-Funktion nutzen will, ein gültiges Berechtigungszertifikat von der Vergabestelle vorweisen und einen eID-Server betreiben (oder den entsprechenden eID-Service anmieten). Das ist sicher etwas aufwändig. Geht es nicht etwas einfacher? Wenn man sich an der Lösung Sofortüberweisung orientiert, so könnte man auf die Idee kommen, einem Nutzer mittels "man-in-the-middle" quasi dabei über die Schulter zu schauen, wie er eine Onlineauthentisierung gegenüber einem Dienstanbieter mit Berechtigungszertifikat durchführt. Schreiben Sie eine App, die eine Piggyback-Authentisierung via den vom Bürgerportal der Stadt Würzburg angebotenen Dienst zur Selbstauskunft nutzt. Das Lesegerät für den nPA soll über Bluetooth mit dem nPA verbunden werden und der Leser soll eine eigenen PIN-Eingabe und Anzeige der Transaktion ermöglichen.
Links:
Rund um den eIDClientCore
Der eIDClientCore ist eine in Entwicklung befindliche Bibliothek, die die Kernfunktionalitäten für den Zugriff auf die eID-Funktion des neuen Personalausweises (nPA) und des elektronischen Aufenthaltstitels (eAT) bereitstellt.
GUI mit PIN-Management
Schreiben Sie ein portables GUI für den eIDCC, womit als erstes schon mal das PIN-Management (PIN-Neusetzen, ggf. PUK, ) realisiert werden kann.
Initialisierung, Signaturerstellung mit dem eIDClientCore
(Entwicklung nur in der BDr, Erfahrung mit Android notwendig!) Der neue Personalausweis ist als sichere Signaturerstellungseinheit vorbereitet. Um diese Funktion zu nutzen, kann ein QES-Signaturzertifikat passend zum auf der Karte generierten Schlüssel nachgeladen werden. In wieweit kann zumindest funktional, der eIDCC hierzu verwendet werden?
Links:
Mentor:
RSA-PSK Unterstützung für mod_ssl
Das Verschränken von kryptografisch mit SSL/TLS gesicherten Kanälen ist in vielen Webanwendungen wünschenswert. Bislang ist ein Handshake der einen "pre shared key" in Kombination mit RSA gemäß RFC 4279 bereitstellt, für openSSL nur als Patch (http://www.internet-sicherheit.de/service/tools/patches/) (auch für eine nicht ganz aktuelle Version) verfügbar. In dem Apachemodul mod_ssl ist diese Methode jedoch noch gar nicht vorgesehen. Hier wäre es sinnvoll, Ideen zu entwickeln, wie RSA-PSK hier Unterstützung finden kann.
Mentor:
Pseudonyme Signaturen mit dem nPA
In dem Paper "Domain-Specific Pseudonymous Signatures for the German Identity Card" wird ein Vorschlag gemacht, wie pseudonyme Signaturen dem (zukünftigen nPA) gemacht werden können. Das ermöglicht Signaturen mit dem nPA die nicht als QES angesehen werden, sondern eher zur Bestätigung oder Auslösung von Transaktionen genutzt werden können. Lesen und verstehen Sie die Ideen. Implementieren Sie dieses Protokoll, indealer Weise in OpenPACE.
Links:
Mentor:
Sichere Wiki-Konfiguration / Migration (Alexander)
Ein Wiki ist seiner Natur nach ein offenes System, in welchem der "Mitmachgedanke" weit vorne steht. Leider gibt es dann doch häufig automatisierte Angriffe, die diese Eigenschaft ausnutzen. So fand sich auch in unserm Wiki viel SPAM.
Versuchen Sie eine Kopie unseres Wikis auf eine aktuelle Codebasis zu heben. Dokumentieren Sie Ihre einzelnen Schritte. Treffen Sie eine begründete Auswahl an Zusatzpaketen zur Integration von Formeln, Bildern, ... und versuchen Sie eine möglichst sichere Konfiguration zu erreichen. Ansatzpunkte könnten die Verwendung von Captchas, sowie Beschränkungen zum anlegen von Nutzeraccounts sein.
Mentor: Wolf Müller, Wolfgang Gandre
UEFI Secure Boot
Setzen sie eine virtuelle Maschine auf, welche UEFI Secure Boot verwendet.
- OpenSUSE mit UEFI Secure boot in KVM: http://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm
- Secure Boot in Fedora: http://mjg59.dreamwidth.org/12368.html (allgemein gibt es in dem Blog viele Informationen zu Secure Boot)
Alternativ/zusätzlich sind auch (U)EFI rootkits dieses Jahr ein heißes Thema:
- https://program.sigint.ccc.de/fahrplan/system/attachments/24/original/efi_rootkits.pdf
- http://ho.ax/De_Mysteriis_Dom_Jobsivs_-_Syscan.pdf
Mentor:
AeroFS überwachen
Der "nicht-Cloud-Speicher" AeroFS speichert im Gegensatz zu Diensten wie Dropbox oder Wuala die Daten ausschließlich auf den eigenen Rechnern und synchronisiert zwischen diesen via LAN oder Internet verschlüsselt. Jedenfalls wird das behauptet. Man könnte sich anschauen, inwiefern es möglich ist, dieses Versprechen zu überprüfen.
- Weitere kreative Vorschläge sind willkommen!
- Viel Erfolg!
- Kontakt: Wolf Müller