Security by Configuration

There is an interesting article on Linux.com about configuration-centered security, “Configuration: The Forgotten Side of Security” (by Bruce Byfield). Whereas most security products on the market follow the approach of reactive security (e.g., anti-virus scanners, patches), a proactive approach includes security aspects in the design and installation of a computer system. Intuitively, taking security into account right from the start should be the better approach because design flaws in a software architecture are harder to fix later. The article gives some hints why the computer industry has not followed this approach. One reason mentioned is the tradeoff between security and convenience. But counter-examples are given (for instance, Mac OS X *g*), and an IT professional is cited that “usability and security are not mutually exclusive”. And I think that is absolutely right.

The article lists the basic goals of system configuration, which are derived from basic security principles (e.g., least privilege, containment, etc.):

• Build for a specific purpose and only include the bare minimum needed to accomplish the task.


• Protect the availability and integrity of data at rest.


• Protect the confidentiality and integrity of data in motion.


• Disable all unnecessary resources.


• Limit and record access to necessary resources.

I think these goals should be applied especially for online banking applications in the context of phishing attacks. Having full-featured, complex web browser applications seems not to be the right basis for such tasks, does it? Well, maybe the idea of browser compartments is a good starting point…

Towards Multicolored Computing - Compartmented Security to Prevent Phishing Attacks

This is a paper that I have written together with Sebastian Gajek, Ahmad-Reza Sadeghi, and Christian Stüble. I have presented the paper at the 1st Benelux Workshop on Information and System Security (WISSec 2006) in Antwerpen, Belgium, last month. The paper aims at making the first steps towards the design and implementation of an open source and interoperable security architecture that prevents both classical phishing (e.g., e-mails luring unaware users to faked web sites) and the new emerging malware phishing, i.e., malicious software specifically tailored to certain services.

Our approach is based on the ideas of multicolored computing (e.g., red for the risky and green for the trusted domain), and a trusted wallet for storing credentials and authenticating sensitive services. Our solution requires no special care from users for identifying the right web sites while the disclosure of credentials is strictly controlled. In the paper we present the main idea of how to integrate countermeasures against phishing and malware into one sound security architecture. We also briefly sketch how to implement this architecture based on the PERSEUS security framework, which utilizes Trusted Computing functionality and virtualization. The former is used to preserve system integrity, and the latter provides compartment isolation and software re-use.

To establish a trusted path to the trusted wallet we make use of the Secure GUI subsystem that is developed by the EMSCB project for the PERSEUS system. the Secure GUI subsystem provides to each compartment an isolated graphics framebuffer, which are then multiplexed or switched to on the screen. To enable the user to authenticate the currently displayed compartment, the Secure GUI has a reserved area on the screen to which no compartment has access. The Secure GUI displays the compartment identifier and the color indicating a trusted (green) or untrusted (red) compartment there.

You can download the paper as PDF.

TCG Inside? - A Note on TPM Specification Compliance

This is a paper that I have written together with Ahmad-Reza Sadeghi, Marcel Selhorst, Christian Stüble and Christian Wachsmann, and I am going to present it at the First ACM Workshop on Scalable Trusted Computing (STC’06) in Fairfax, Virginia, USA, next month. The paper describes the first steps towards having an independent means for testing the compliance of Trusted Platform Module (TPM) chips according the TCG specifications. Besides presenting a test strategy, we have also developed a prototype test suite. Although the currently implemented tests do not cover the complete TCG specification, our test results show that many TPM implementations do not meet the TCG specification and have bugs. We also discuss that non-compliance may have crucial impact on security. For instance, non-compliant error return codes may be useful for profiling TPM chip models. These profiles may then be used in further attacks, e.g., password dictionary attacks.

We have already published first results of our tests in a technical report, which was also mentioned in the c’t magazine (“Sicherheits-Chips auf den Zahn gefühlt”, in German). For more information, see our project website on TPM Compliance Tests.