W2013-ITS: Difference between revisions
m (→Themen) |
m (→Themen) |
||
Line 1: | Line 1: | ||
=Themen= |
=Themen= |
||
⚫ | |||
⚫ | Wenn man die Annahme, dass private Schlüssel immer privat bleiben fallen muss, stellt sich die Frage, ob bereits aufgezeicheter SSL/TLS-Traffic der zu einem früheren Zeitpunkt mit diesem Schlüssel initiiert wurde, im nachhinein entschlüsselt werden kann. Versuchen Sie Lösungen zu finden, damit in der TLS-Aushandlung möglichst geeignete Chiphersuites zwischen dem verwendeten Browser und dem Webserver (ephemerales Schlüsselmaterial, möglichst schneller Handshake, robuste Verschlüsselung und MAC) ausgehandelt werden. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | Um ausreichende Sicherheitsreserven zu haben werden aktuell für RSA Shlüssellängen von 2048 oder 4096 Bit verwendet. Abhilfe könnte die Kryptografie mit elliptischen Kurven schaffen. Hier wird mit kürzeren Schlüsseln vergleichbare Sicherheit erreicht. Bisher ist die Verwendong noch eher exotisch. Wo bekommt man so ein Zertifikat her? Welche Klienten kommen damit klar, wo gibt es Probleme? Können beide (RSA und ECC) auf der gleichen Domain in der Art verwendet werden, dass wenn der Klient kein ECC beherrscht, dass ein Fallback auf RSA erfolgt? |
||
⚫ | |||
⚫ | |||
⚫ | |||
==Untersuchung NFC Interface auf Android Telefonen== |
==Untersuchung NFC Interface auf Android Telefonen== |
||
Line 33: | Line 17: | ||
* [https://developer.android.com/reference/android/nfc/tech/MifareClassic.html Mifare Classic Android API] |
* [https://developer.android.com/reference/android/nfc/tech/MifareClassic.html Mifare Classic Android API] |
||
* [https://sarwiki.informatik.hu-berlin.de/NFC_unter_Android NFC unter Android] |
* [https://sarwiki.informatik.hu-berlin.de/NFC_unter_Android NFC unter Android] |
||
Mentor: |
|||
==Selbstauskunft "in-the-middle"== |
|||
⚫ | |||
* [https://www.buergerserviceportal.de/bayern/wuerzburg/bspx_selbstauskunft Selbstauskunft] |
|||
⚫ | |||
⚫ | Wenn man die Annahme, dass private Schlüssel immer privat bleiben fallen muss, stellt sich die Frage, ob bereits aufgezeicheter SSL/TLS-Traffic der zu einem früheren Zeitpunkt mit diesem Schlüssel initiiert wurde, im nachhinein entschlüsselt werden kann. Versuchen Sie Lösungen zu finden, damit in der TLS-Aushandlung möglichst geeignete Chiphersuites zwischen dem verwendeten Browser und dem Webserver (ephemerales Schlüsselmaterial, möglichst schneller Handshake, robuste Verschlüsselung und MAC) ausgehandelt werden. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
Mentor: |
|||
⚫ | |||
⚫ | Um ausreichende Sicherheitsreserven zu haben werden aktuell für RSA Shlüssellängen von 2048 oder 4096 Bit verwendet. Abhilfe könnte die Kryptografie mit elliptischen Kurven schaffen. Hier wird mit kürzeren Schlüsseln vergleichbare Sicherheit erreicht. Bisher ist die Verwendong noch eher exotisch. Wo bekommt man so ein Zertifikat her? Welche Klienten kommen damit klar, wo gibt es Probleme? Können beide (RSA und ECC) auf der gleichen Domain in der Art verwendet werden, dass wenn der Klient kein ECC beherrscht, dass ein Fallback auf RSA erfolgt? |
||
Links: |
|||
⚫ | |||
⚫ | |||
Mentor: |
Mentor: |
Revision as of 13:42, 28 August 2013
Themen
Untersuchung NFC Interface auf Android Telefonen
Als erste kleine Übung kann eine App zum Anzeigen des Guthabens auf der Mensakarte entwickelt werden. Weitergehende Aufgaben wären beispielsweise das Brechen von Mifare Schlüsseln auf dem Telefon (also ein Portierung von mfoc). Besonders spannend wäre es zu untersuchen, ob/wie mit dem Telefon die Kartenemulation machbar ist. Dazu gab es dieses Jahr auf der Defon einen Vortrag, bei dem das Tool nfcproxy vorgestellt wurde.
Links:
- libnfc
- nfc-tools
- nfcproxy
- Bauanleitung Cyanogen Mod
- Card Emulation patches für Jelly Bean
- Mifare Classic Android API
- NFC unter Android
Mentor:
Selbstauskunft "in-the-middle"
Links:
Forward Secrecy für Apache
Wenn man die Annahme, dass private Schlüssel immer privat bleiben fallen muss, stellt sich die Frage, ob bereits aufgezeicheter SSL/TLS-Traffic der zu einem früheren Zeitpunkt mit diesem Schlüssel initiiert wurde, im nachhinein entschlüsselt werden kann. Versuchen Sie Lösungen zu finden, damit in der TLS-Aushandlung möglichst geeignete Chiphersuites zwischen dem verwendeten Browser und dem Webserver (ephemerales Schlüsselmaterial, möglichst schneller Handshake, robuste Verschlüsselung und MAC) ausgehandelt werden.
Links:
Mentor:
ECC Zertifikate im Apache
Um ausreichende Sicherheitsreserven zu haben werden aktuell für RSA Shlüssellängen von 2048 oder 4096 Bit verwendet. Abhilfe könnte die Kryptografie mit elliptischen Kurven schaffen. Hier wird mit kürzeren Schlüsseln vergleichbare Sicherheit erreicht. Bisher ist die Verwendong noch eher exotisch. Wo bekommt man so ein Zertifikat her? Welche Klienten kommen damit klar, wo gibt es Probleme? Können beide (RSA und ECC) auf der gleichen Domain in der Art verwendet werden, dass wenn der Klient kein ECC beherrscht, dass ein Fallback auf RSA erfolgt?
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:
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:
seccomp
seit linux 3.5 gibt es einen erweiterten seccomp modus, der es erlaubt syscalls via einem bpf programm zu "filtern".
Aufgabe könnte sein einen kleinen "compiler" zu bauen der text configs in entsprechende bpf programme übersetzt.
Blogeintrag zur nächsten Chrome sandbox auf Basis von seccomp: http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html
Mentor:
Weitere kreative Vorschläge sind willkommen!
Viel Erfolg!
Kontakt: Wolf Müller