> Hi,
>
>> 1. First, about what you call the « post-mortem analysis ». I like the
>> term but I want to know whether it is a canonical term for security
>> experts or something that might need a bit more explanation.
>
> I think the keyword here is forensics. Could go instead of analysis.
Hmm… Having a look at the wikipedia entries for 'forensics' and
'computer forensics' this term is explicitly linked to a legal context, see:
« Forensic science (often shortened to forensics) is the application of
a broad spectrum of sciences to answer questions of interest to a legal
system. »
« Computer forensics (sometimes computer forensic science[1]) is a
branch of digital forensic science pertaining to legal evidence found in
computers and digital storage media. »
I'm not sure we want to be that specific. So I'll stick to 'post-mortem'
and add a drop of plain 'data recovery' to be more explicit.
>> Then, apart from the threat model, the document is not very explicit
>> about this issue. There might not be much to say but I think that it
>> should at least be mentioned in the requirements, part 2 :
>> - What is required for a PELD to prevent from post-mortem analysis?
>> - How do we think this should be provided?
>
> I agree, we should improve this.
See the second patch. I tried to do the following :
2.1.2 Working on sensitive documents:
Be a bit more vague and explain more why the intent should be to go for
a white list approach (without calling it like this) and not keep
anything unless ask to do so.
2.2.1 The goal of the attacker:
Be more explicit about the swap and RAM issues.
2.7 Data recovery requirements:
Adding this part by basically recycling stuff from the old 2.1.2.
>> Again in part 3, while presenting the implementation we should explain
>> more about what Tails does to achieve that. There is a paragraph on
>> host system RAM but I guess we can find more to explain, like :
>> - I could imagine that some LiveDistros detect the swap areas and use
>> them. Do we ? ;)
>
> Hints to the one who will write this part:
>
> - not using live-boot's swapon option
> - config/chroot_local-hooks/03-noswap
> - config/chroot_local-hooks/05-disable_swapon
Great. The first patch is about that. Even though I couldn't find the
13swap file deleted by config/chroot_local-hooks/03-noswap anywhere.
>> - I could imagine that some LiveDistros read the disks and possibly
>> mount the available partitions automatically. Same thing.
>
> Hints to the one who will write this part:
>
> - grep nopersistent config/amnesia
> - probably a few GConf settings in
> config/chroot_local-includes/usr/share/amnesia/gconf/
Didn't do that ;)
>> - I wonder how Tails addresses the requirements in 2.1.2, for example
>> this one : « The usage of encrypted removable storage devices (such
>> as USB sticks) should be encouraged. »
>
>> I think this whole post-mortem analysis thingie is the real difference
>> to put forward while talking to the Tor people ; bringing their privacy
>> concerns further than just the Internet connection. You can be a Tor
>> freak and get the same Tor configuration as Tails on your own system
>> but you won't get the same post-mortem analysis protection.
>
> I agree, we should insist a bit on this topic.
--
From 26585a8bc52fe5bf593c1e0f79d9fb266a765ff3 Mon Sep 17 00:00:00 2001
From: T(A)ILS developers <amnesia@???>
Date: Tue, 4 Jan 2011 18:12:15 +0100
Subject: [PATCH 1/2] Design draft: add implementation part for the swap
---
wiki/src/contribute/design/draft.mdwn | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/wiki/src/contribute/design/draft.mdwn b/wiki/src/contribute/design/draft.mdwn
index 3dacc17..b44947b 100644
--- a/wiki/src/contribute/design/draft.mdwn
+++ b/wiki/src/contribute/design/draft.mdwn
@@ -686,12 +686,10 @@ servers.
### 3.5.12 Host system swap
-**FIXME**: explain T(A)ILS does its best not to use any swap partition
-that could be found at runtime:
-
+The ability to use a swap partition on local storage to extend the RAM
+is completely disabled by:
- not using live-boot's swapon option
-- config/chroot_local-hooks/03-noswap
-- config/chroot_local-hooks/05-disable_swapon
+- replacing the /sbin/swapon binary by a dummy script running /bin/true
### 3.5.13 Host system RAM
--
1.7.2.3
From 2164624dabd04fda2d7e840ecb174a7b0c174fd0 Mon Sep 17 00:00:00 2001
From: T(A)ILS developers <amnesia@???>
Date: Tue, 4 Jan 2011 18:17:24 +0100
Subject: [PATCH 2/2] Design draft: add some more about post-mortem equipment analysis
---
wiki/src/contribute/design/draft.mdwn | 108 +++++++++++++++++----------------
1 files changed, 55 insertions(+), 53 deletions(-)
diff --git a/wiki/src/contribute/design/draft.mdwn b/wiki/src/contribute/design/draft.mdwn
index b44947b..bb33573 100644
--- a/wiki/src/contribute/design/draft.mdwn
+++ b/wiki/src/contribute/design/draft.mdwn
@@ -35,17 +35,6 @@ Other design documents:
review process quicker
* the *Reproducibility* section is probably worth merging in the
specification
-- be more explicit about the post-mortem forensics issue. There might
- not be much to say but I think that it should at least be mentioned
- in the requirements, part 2:
- * What is required for a PELD to prevent from post-mortem analysis?
- * How do we think this should be provided?
-- More generally this whole post-mortem analysis thingie is the real
- difference to put forward while talking to the Tor people; bringing
- their privacy concerns further than just the Internet connection.
- You can be a Tor freak and get the same Tor configuration as T(A)ILS
- on your own system but you won't get the same post-mortem analysis
- protection.
# 1 Introduction
@@ -75,23 +64,10 @@ overlay network Tor.
### 2.1.2 Working on sensitive documents
The PELD also aims at providing a "safe" environment to work on
-sensitive documents:
-
-- No trace must be left on local storage devices unless the user
- explicitly asks for it.
-- The usage of encrypted removable storage devices (such as USB
- sticks) should be encouraged.
-- No specific user information should be left in the sensitive documents made
- on or published with the PELD (for example EXIF data).
-
-**FIXME**: I don't really understand the last requirement. It seems to
-me this implies the PELD should modify on-the-fly any file present on
-a USB stick, e.g. (but not only) when a user selects it in the web
-browser to upload it; I doubt this is actually desirable. Providing
-tools to remove metadata from documents would be a welcome bonus but I
-am not sure about forcibly doing so. Also, "no specific user
-information" seems pretty vague to me, as well as the restriction of
-this requirement to "sensitive documents".
+sensitive documents. It is impossible for such a system to determine
+which information is sensitive and which is not. Thus, the PELD should
+not store any data on storage devices unless the user explicity asks to
+do so and should not leave any trace of its usage on the equipment.
### 2.1.3 Portability
@@ -139,13 +115,16 @@ attackers.
- **Eavesdrop on sensitive data**: The Tor network only prevents the
data from being traced (according to Tor's threat model) but does not
protect it from eavesdropping.
-- **Post-mortem user activity and sensitive data recovery (forensics)**:
+- **Data recovery after system shutdown**:
"Normal" operating systems keep a lot of traces about their users'
Internet activities (notably browser cache and cookies) on local
storage media; similarly, working on a sensitive document with a
- "normal" operating system is likely to leave traces of this
- document. The adversary may want to recover such information by
- analyzing the equipment that has been used.
+ "normal" operating system is likely to leave traces of this document.
+ User's data can remain on the equipment even after the machine is
+ shut down; be it stored in the filesystem or in the memories, both
+ RAM and swap, which might as well retain data (for example encryption
+ keys or passwords). The adversary may want to recover such
+ information by analyzing the equipment that has been used.
### 2.2.2 Capabilities, methods and other means of the attacker
@@ -164,9 +143,9 @@ attackers.
applications' services and features to get identifying information.
Examples are JavaScript and Java applets in web browsers, CTCP
queries in IRC clients, etc.
-- **Post-mortem equipment analysis**: The adversary might raid the
- user at any moment and then confiscate and analyse the equipment,
- storage media and memory in particular.
+- **Data recovery and post-mortem equipment analysis**: The adversary
+ might raid the user at any moment and then confiscate and analyse the
+ equipment, storage media and memory in particular.
- **Live physical monitoring**: the adversary might be physically
monitoring the computer while the PELD is running on it.
@@ -279,9 +258,32 @@ thread on the or-talk mailing-list).
Any exception to these rules must be thoroughly thought of and
properly documented.
-## 2.7 User interface and applications
+## 2.7 Data recovery requirements
+
+In order not to leave any undesired trace after use and to prevent from
+post-mortem analysis of the equipment:
+
+- No trace must be left on local storage devices unless the user
+ explicitly asks for it.
+- Both the swap and the RAM memories should be clear from any user
+ data after use.
+- The usage of encrypted removable storage devices (such as USB sticks)
+ should be encouraged.
+- No specific user information should be left in the sensitive
+ documents create or published by the user (for example EXIF data).
+
+**FIXME**: I don't really understand the last requirement. It seems to
+me this implies the PELD should modify on-the-fly any file present on a
+USB stick, e.g. (but not only) when a user selects it in the web
+browser to upload it; I doubt this is actually desirable. Providing
+tools to remove metadata from documents would be a welcome bonus but I
+am not sure about forcibly doing so. Also, "no specific user
+information" seems pretty vague to me, as well as the restriction of
+this requirement to "sensitive documents".
+
+## 2.8 User interface and applications
-### 2.7.1 General user interface
+### 2.8.1 General user interface
The user should be able to do all relevant things with easy to use
graphical interfaces. As such it should be presented a solid,
@@ -289,7 +291,7 @@ user-friendly desktop environment with all the expected features after
booting: file management, system settings configuration, support
applications etc.
-### 2.7.2 Internet applications
+### 2.8.2 Internet applications
At minimum, clients for the following Internet activities must be
supported:
@@ -322,14 +324,14 @@ also configured in such a way. In general, as little information as
possible should leak about the user, the applications used and the
system settings.
-### 2.7.3 Document production applications
+### 2.8.3 Document production applications
**FIXME**: the PELD intents to allow "Working on sensitive documents"
=> software for non-Internet activities: word processor, bitmap and
vector graphics, DTP, PO editor, sound recording and editing,
printer and scanner support.
-### 2.7.4 Tor
+### 2.8.4 Tor
Tor should be setup to enable its DNS server (`DNSPort`) and transparent
proxy (`TransPort`, `TransListen`) so the functionality specified in the
@@ -344,7 +346,7 @@ and thus some means of authentication will be required
(`CookieAuthentication` preferably) to hinder attacks on the Tor
software.
-### 2.7.5 Hardened tool chain and compiling
+### 2.8.5 Hardened tool chain and compiling
**FIXME**: change the "compile all software" recommendation into
something like "carefully balance the added security provided by
@@ -359,7 +361,7 @@ compiler level stuff is necessary for utilizing the kernel security
features. Because of this it is recommended to compile essentially all
software from sources to take benefit from these security features.
-### 2.7.6 Cryptographic tools
+### 2.8.6 Cryptographic tools
Tools for securely signing, verifying, encrypting and decrypting files
and messages should be available. In particular some implementation of
@@ -373,15 +375,15 @@ the current commonly agreed best practices.
Tools for creating encrypted storage containers are also recommended.
-### 2.7.7 "Virtual" input system
+### 2.8.7 "Virtual" input system
As one of the PELD intent is to permit usage of untrusty computers while
preserving anonymity, measures should be taken against hardware that
-might prevent it, such as hardware
+might prevent it, such as hardware
[keyloggers](
http://en.wikipedia.org/wiki/Keylogger). Thus a virtual
keyboard (usable with the mouse) should be available.
-### 2.7.8 Entropy
+### 2.8.8 Entropy
Some crucial applications of the PELD, such as the Tor client, make
heavy use of cryptographic techniques and therefore rely on a high
@@ -394,14 +396,14 @@ Using an auxiliary entropy source such as
[haveged](
http://www.irisa.fr/caps/projects/hipsor/) should thus be
considered.
-## 2.8 Usability
+## 2.9 Usability
Security is usually hard to get. Therefore steps need to be taken in
order to make the user more comfortable with the PELD, and also to
educate the user about the specific risks and quirks with respect to
anonymity on the Internet.
-### 2.8.1 Internationalization
+### 2.9.1 Internationalization
The user should be able to easily select his of her language of
preference. User applications should be localized to fit this
@@ -411,7 +413,7 @@ The PELD documentation, either online or shipped within, should be
easily translatable. Software written specifically for the PELD should
be developed with i18n/l10n-awareness in mind.
-### 2.8.2 Education and user help
+### 2.9.2 Education and user help
The PELD should include an easily read document explaining how to use
it and its software securely. The user should be assumed to only have
@@ -425,23 +427,23 @@ issues. A PELD running copy should therefore notice it is affected by
known security issues and notify the user if a newer release fixes
some.
-## 2.9 Other considerations
+## 2.10 Other considerations
-### 2.9.1 Maintainability
+### 2.10.1 Maintainability
The procedure to update the PELD should not be prohibitive to provide
timely software updates to address issues related to security or
anonymity. A scripted, automatic build procedure is greatly preferred
to manually setting up things.
-### 2.9.2 Sustainability
+### 2.10.2 Sustainability
PELD development should be a team work rather than a one person work,
and the deep knowledge of this work should be shared between the team
members. Thus the development infrastructure should be thought and
deployed in order to share this knowledge.
-### 2.9.3 Open-source transparency
+### 2.10.3 Open-source transparency
For the sake of transparency the use of open-source software is
encouraged. Binary blobs should only be used when no good alternatives
@@ -451,7 +453,7 @@ firmwares.
Similarly, it is recommended for the PELD itself to be open-source, and
well documented to help security analysis by third-parties.
-### 2.9.4 Easy feedback
+### 2.10.4 Easy feedback
In order to collect bug reports, wanted features and so on, the PELD
project should offer easy ways for end-users to provide feedback to the
--
1.7.2.3
