Trusted Virtual Domains (TVDs) are a new framework for the implementation of secure multi-domain / single-infrastructure computer networks like centralized data centers or single organizational LANs that span over different physical places. A Trusted Virtual Domain is a set of virtual hosts that are distributed across multiple physical machines and that share a common security policy. Computational resources from different owners share the same physical infrastructure, while strong isolation is enforced between members of different TVDs by the underlying security framework.
Since most existing TVD implementations are research prototypes, not available for the public, and focus on servers and data centers, there are only few efforts on secure desktop environments. To fill this gap, we present in this paper an open-source implementation of TVDs based on the OpenSolaris operating system. We leverage several of its existing features (e.g., lightweight virtualization, security labels and a secure graphical user interface) and extend OpenSolaris with components for automated management and policy enforcement to create a usable desktop implementation of TVDs. This includes the transparent encryption of external storage and home directories of users, restriction of copy-and-paste according to the TVD policy, efficient deployment of images for user environments, and a central management interface for the administration.
The picture above shows the architecture of our TVD on OpenSolaris implementation. The general idea of our architecture is to use the built-in lightweight virtualization features of OpenSolaris, i.e., the zones, to separate the different TVDs from each other. The global zone executes the necessary management code, and deploys and starts the virtualized environments (zones)
representing a TVD. Our system relies on the OpenSolaris kernel which enforces and provides security features such as mandatory and discretionary access control. For intra-TVD communication, our TVD layer establishes logical links between the virtualized environments on different platforms that belong to the same TVD. This logical network is completely isolated from any network traffic from outside that TVD, thus establishing secure channels between the TVD members. The transmission of policies and keys, as well as management messages, is separated in another logical network which cannot be accessed by any TVD. This management network is also used for accessing the network storage that is provided to every user as persistent storage mechanism.
OpenSolaris offers several interesting features, the most prominent ones we used are the filesystem ZFS for our zone image deployment, and the secure graphical user interface (Secure GUI). The screenshot below shows the graphical desktop environment with the trusted path functionality: The GUI system always shows to which TVD a window or virtual screen belongs to (red TVD or green TVD in this example), and this information cannot be faked as the top-most menu bar, the trusted stripe, is under control of the Secure GUI system. Applications running in the TVD zones cannot modify or fake this information.
In this work, we have shown that it is possible to implement TVDs for end-user desktop systems based on OpenSolaris. Our TVD framework features integrated management and transparent data encryption, an efficient deployment of zone images, and puts a particular focus on the ease of administration. Our implementation adds a TVD layer to the OpenSolaris system without any modification of the existing kernel or core security features. Demo videos and source code will be available on the project website.
Paper | Slides
From the abstract:
The German compulsory health insurance system will introduce an electronic health card (eHC) in the near future. The eHC is supposed to enable new applications like securely storing electronic health records of patients in a central data center infrastructure so that health professionals can access these data via a common network. In this context, the card management system (CMS) is of special interest since it is used to personalize, issue, and maintain the cards. In this paper, we analyze the functional requirements specification of the CMS in Germany and identify several conflicting and ambiguous requirements. As the most important result, the specification defines technical measures that are insufficient to protect the data and data sovereignty of the patient. We discuss the resulting consequences, which might be helpful to improve the system design before its final deployment.
We present two models of e-health clouds: a simple one pertaining Personal Health Records (PHRs), and an advanced one pertaining Electronic Health Records (EHRs). We point out the difference in the paper, and discuss three major security problem areas: (i) data storage and processing, (ii) infrastructure management, and (iii) usability.
To solve on of the problems, i.e., that of client platform security, we propose to construct privacy domains for the patients’ medical data as a technical measure to support the enforce- ment of privacy and data protection policies: Systems (e.g., a client PC) must be able to partition execution environ- ments for applications into separate domains that are iso- lated from each other. Data is kept within a privacy domain, and the domain infrastructure ensures that only authorized entities can join this domain. Moreover, data leakage from the domain is prevented by the security architecture and the domain infrastructure. Therefore, the same system can be used for different work flows that are strictly isolated. The following picture shows the architecture:
Moreover, we discuss in the paper open research challenges in e-health scenarios, in particular those related to healthcare telematics infrastructures.
This is a paper I wrote together with Hans Löhr and Ahmad-Reza Sadeghi. It was presented at the SPattern 2010 workshop, co-located to the ARES 2010 conference. This paper describes two fundamental concepts of trusted computing in terms of security patterns, namely the Secure Boot pattern and the Secure Storage pattern. Although security patterns exist for operating system security, access control, and authentication, there have not been any on trusted computing particularly (to the best of our knowledge). Secure boot is at the heart of most security solutions and secure storage is fundamental for application-level security: it ensures that the integrity of software is verified before accessing stored data. Our paper aims at complementing existing system security patterns by presenting the common patterns underlying the different realizations of secure boot and secure storage.
Here's the link to the paper (pdf).
This is a paper I wrote together with Thomas Fischer and Ahmad-Reza Sadeghi. It was presented at SPattern 2009 workshop in Linz. Several aspects of secure operating systems have been analyzed and described as security patterns. However, previous patterns do not cover explicitly the secure interaction of users with the user interface of applications. A secure user interface system has to provide a trusted path between the user and the application the user intends to use. The trusted path must be able to ensure integrity and confidentiality of the transmitted data, and must allow for the verification of the authenticity of the end points. Our paper presents a pattern for secure graphical user interface systems and evaluates its use in different implementations. This pattern shows how to fulfill the security requirements of a trusted path while preserving, in a policy-driven way, the flexibility that graphical user interfaces generally demand.
The central idea is to mediate all user input/output through a Secure User Interface (SUI) system, and to separate the content drawn by applications from what is actually displayed on the screen. The SUI controls solely the graphics rendering hardware and the input events from the user input devices (typically, keyboard and mouse). The picture shows the participating elements.
Here's the paper (pdf).
So I also watched that video and quickly recognized that this was a phishing attack using social engineering tricks. Moreover, after a quick research on Youtube I discovered several such videos for different games. They all share a common pattern and trick the users to send their password to a certain e-mail address.
Basically, all these videos promise something like "how to hack an account" or "how to get 1000 gold". They claim that they discovered a hidden function that usually would be used by the game masters of that online game. To activate the function, you would only need to send an e-mail with a certain structure to a particular e-mail address. Within those structures is always the account name and account password (that's the phishing indicator #1 - NEVER send passwords via e-mail somewhere!).
Moreover, all those videos name as e-mail address to send the request for the hidden function some address which is never under the domain of the corresponding company developing or running the online game. Mostly, these are semi-anonymous e-mail address @gmx.net or @gmail.com (phishing indicator #2 - similar, but not exactly correct internet addresses).
Here are some examples, just search on YouTube:
(Warning: Phishing attacks! Do not follow what they tell you!!)
- Phishing video "How to Scam an account on WoW!!!"
- Phishing video "WoW Account Hack [Easy]" (german)
- Phishing video "Herr der Ringe Online Account Hack [Easy]" (german)
And there are even more. Some of them are online since two years and more! I can't believe this still works. But, like other Phishing in e-commerce and online banking, there are still a lot of people who are tricked by these attacks.
I think it would be a good idea and help users to describe these attacks on the web sites of the online game manufacturers and also on the welcome screen when you log in to your account in the game. There are still people who do not understand these attacks -- we need to tell them!
Trusted Privacy Domains -- Challenges for Trusted Computing in Privacy-Protecting Information Sharing
From the abstract: