Arbeitsdetails https://avt.hsr.ch/DetailAnsicht.aspx?Arbeit=1050
Automatic Certificate Collection in Secure Messaging
Studiengang: Informatik (I)
Semester: HS 2009/2010 (14.09.2009-14.02.2010)
Durchführung: Bachelorarbeit, Diplomarbeit, Studienarbeit
Fachrichtung: Sicherheit
Institut: ITA: Internet-Techn. und Anwend.
Gruppengrösse: 2 Studierende
Status: Aufgabenstellung in Arbeit
Verantwortlicher: Steffen, Andreas
Betreuer: Steffen, Andreas
Gegenleser: [Nicht definiert]
Experte: Dr. Ralf Hauser
Industriepartner: PrivaSphere AG
Ausschreibung: Introduction
Standard e-mail[1] is over 25 years old and is increasingly substituting conventional
paper mail, but it miserably fails at any security goal except for "availability". So while
there is information flow, there is little control over it from a security point of view: no
integrity, no confidentiality, no authenticity, and no accountability.
The text-book answer is certificates, i.e. Public Key Cryptography (PKI). The idea is
that based on asymmetric cryptography, it is possible to equip users hopefully even all
citizens with key-pairs allowing them authenticate, sign, and encrypt, etc. In some
cases, this is even dubbed as giving them an "electronic identity" which normally
involves putting this material on some security hardware like a modern USB stick.
While theoretically appealing, this approach concept has met surprisingly little
acceptance even in countries where every citizen was mandatorily issued a key pair on
an ID card by her/his government. Besides many other reasons, an important finding is
that even if you plan to use your newly obtained encryption/signing key pairs, your
counterpart typically doesn’t own any, or doesn’t know how to use it.
While other infrastructures alleviate this problem by mediating security on a
guaranteed minimum level between heterogeneous sender-recipient communities[2],
pure PKI based secure messaging requires both parties to adhere to the exact same
standards. That being typically not the case is termed "negative network effects": "It
doesn’t work for me if you are not equally equipped as I".
There is even a further deteriorating aspect to this: While the concept of a directory
providing abundant personal (contact) information about the contained subjects was
sought to be generally accepted, it turned out that because of head-hunters,
competitive intelligence, and other activities along these lines, institutions have become
very reluctant to publish directory information. There are even some scientists that
claim that digital certificates that bind cryptographic public keys to identities are the
most detrimental to privacy since they make the data trail one leaves in the internet
non-repudiatable unless one repudiates everything achieved with a particular key pair.
It is however legally ok to use the public key certificates of your counterparts and also
re-use them inside your own company or share them with interested parties.
A system to support this would partially overcome at least the problem that there are
only very few directories for certificates.
Thesis Objectives
Create a scanner that extracts certificates from a mail-stream, validates them and
stores them based on a set of criteria such as which CA issued them.
1 of 2 27.05.2009 12:22
Arbeitsdetails https://avt.hsr.ch/DetailAnsicht.aspx?Arbeit=1050
Create a protocol that encrypts an outbound mail-stream with the certificates available
if applicable and allows the sender to possibly request unencrypted copies (e.g. if they
are travelling without their private decryption key) in some scenarios.
Work Plan (To be refined with the students)
Describe the mail types that could be a source of certificate extraction.
Design a repository to hold the certificates
Draft and assess a rule-set when and how certificates should be stored/replaced
/deleted.
Design a rule-set in what cases an outbound mail stream should be encrypted
(possibly not if the receiving MTA can be reached with the STARTTLS[3]
mechanism).
Devise and evaluate a mechanism how recipients can request unencrypted
copies (simply ask the sender to resend, hold copies at the encrypting hop, other
…).
Design a directory including history function leveraging the certificate repository.
Optional
Create a prototype for such a scanner within the PrivaSphere platform.
Create a prototype for such a encrypter within the PrivaSphere platform.
Create a prototype for a certificate directory within the PrivaSphere platform.
References
[1] Version 3 of SMIME (RFC 2633)
[2] https://www.privasphere.com
[3] SSL/TLS as per RFC 2487
[4] http://www.postfix.org
Voraussetzungen:
Interest in e-mail security, threat analysis, end-user security processes, testing
scenarios.
Strong conceptual and design skills for world-wide networking and messaging.
Java, e-mail, Linux, Postfix[4], SVN, Bugzilla.
Bewerbungen: [Keine Bewerbungen vorhanden]
2 of 2 27.05.2009 12:22