When I found this talk by Bruce Schneier, I was instantly interested and expected something technical. Turns out my expectation was wrong, the talk was still very insightful nevertheless.
Schneier talks about security on a very high level. In fact, I'd rather say that it's a good talk on mental models and the human mind in general, with security as an example.
To quote from a transcript I found online (formatting by me),
Now there are several biases in risk perception. A lot of good experiments in this. And you can see certain biases that come up again and again. So I'll give you four.
- We tend to exaggerate spectacular and rare risks and downplay common risks -- so flying versus driving.
- The unknown is perceived to be riskier than the familiar. One example would be, people fear kidnapping by strangers, when the data supports kidnapping by relatives is much more common. This is for children.
- Third, personified risks are perceived to be greater than anonymous risks -- so Bin Laden is scarier because he has a name.
- And the fourth is people underestimate risks in situations they do control and overestimate them in situations they don't control.
This seems to make sense, I found these patterns to exist widely. But he goes on:
And there's another cognitive bias I'll call confirmation bias, where we tend to accept data that confirms our beliefs and reject data that contradicts our beliefs. So evidence against our model, we're likely to ignore, even if it's compelling. It has to get very compelling before we'll pay attention.
This one is really important. Again, it's a pattern that I've noticed often, unfortunately even in my own thoughts.
Again, questions are raised: Is that what we perceive reality? And are we rational beings?
I don't think so. To quote Heinlein:
Man is not a rational animal, he is a rationalizing animal.
Full-system encryption has obvious benefits which I won't explain here. However, there are several downsides, some of them I explained in cryptography on multi user systems. Another downside is that a fully-encrypted system is... secure.
Consider the following two cases:
- Your machine is stolen, which is especially likely with notebooks. Even if you can get it back, the thief or the next illegitimate user finds the system completely unusable and will format your disk. I assume you're keeping backups anyways, but that sucks nevertheless.
- You got no plausible deniability. In fact, having obviously encrypted[1] your system can make you look suspicious or even guilty, even if you only wanted to preserve your privacy. Something like that happens often. After all, a righteous citizen has nothing to hide, right?
With an unencrypted system, you might have a higher chance in catching the thief, as I've seen yesterday. You can watch that talk on youtube[2]. Seriously, watch it, it's hilarious!
Today, then, it turns out that something similar has happened recently.
Additionally, with an unencrypted system, you could prove that you are, in fact, not guilty when being accused of some crime. Okay, you could just hand out the keys, but there is something better: plausible deniability.
Since we still want to use an encrypted system, the idea is to use two of them. The first one, intended for everyday usage, is encrypted and hidden, the second one completely unencrypted and unprotected, but silently tracks the machine, monitors the users interactions and is backdoored and accessible for you by default.
I'm quite sure that something like what has been described in above links won't work often, at least not completely. But it might help. And setting something up like this costs time only once and does not waste that much hard drive space. It might be worth trying.
I'll save the concrete setup for another post, but here's the basic approach[3]:
- Perform a regular setup of the fake system of your choice. Remember: it has to be usable for everyone with physical access. Leave a large enough part of the disk unpartitioned for the real thing.
- It also has to be usable for you via the net. Setup the required software.
- Start a LiveCD or similar. You don't want to leave traces in the fake system.
- Set up loopback devices to somewhere in the unformatted space. These are your systems partitions. Note the start addresses and sizes.
- Set up the encryption mechanism of your choice (e.g. dm-crypt[4]) on the loopback devices.
- Install.
- Setup an USB memory stick or similar as your boot device. It is unencrypted and holds boot loader, an initial system (e.g. initramfs) that knows addresses and sizes of your hidden partitions, sets up the loopback devices, checks whether the user is authorized and, if so, decrypts and boots the real system.
- Configure the BIOS to try to boot from USB before trying to boot from hard disk.
Congratulations. Your machine runs a neatly backdoored system that boots by default and that everyone can use[5]. The only thing that might tell attackers something is the fact that the system hasn't been used for months and that the disk has some unpartitioned space left. But we all like to have a bit of emergency storage for future partitions, right?
Oh, and keep in mind to completely overwrite the disk with random data before performing the steps above.
- The MBR is still on the disk, readable, and one can see that the content of each of your partitions is, for example, encrypted using dm-crypt.
- In the likely event that this video will get removed, that talk is named "pwned by the owner: what happens when you steal a hacker's computer" and was held at DEF CON 18.
- This approach has not been tested by me in detail, but something along these lines should work.
- But beware! This mechanism might write unencrypted meta-information which may tell that there might be some encrypted data.
- Which might be, in fact, another security problem as they are able to store any data there and claim it was yours.
Introduction
In this post, it is assumed that current operating systems are multi user systems[1].
There exist several reasons for users of a computer to use encryption. To name two common cases, protecting private data is interesting (a) for everyone that owns a laptop because it might easily get lost or stolen. Less interesting, but a probably far more important reason is (b) the protection against political repression, e.g. in form of police raids.
State Of The Art
Current operating systems provide three primary solutions for encryption:
1. Use no encryption at all.
While this is no solution, it is the default for people using operating systems from a certain vendor that cripples your version even further depending on how much money you've paid. If you've bought it, that is.
I assume that this is also the default on systems of the vendor that has recently been satirized in South Park.
But even GNU/Linux distributions install an unencrypted system by default. However, depending on the specific distribution it might be rather easy to install an encrypted one. At least for technically versed people. As often on GNU/Linux, Joe Regular loses.
2. Individual encryption of private data.
On all major operating systems currently used it is possible for users to set up their own cryptographic container of some sort.
Having to manage the container more or less by hand is, however, inconvenient and not completely orthogonal to regular system usage.
Worse, it is even quite insecure. As pointed out in SucurityHole, the environment in which the user has to enter the passphrase may be compromised. This solves (most likely) problems of type (a), but if someone wouldn't mind spending a tiny effort to get your data, he will be able to get it. So this solution is not reliable in case (b).
So, let's assume (a) has been solved. How can we solve (b)?
3. Full-system encryption.
Full-system encryption is usally realized using a single master passphrase that encrypts the whole (and all) hard disks. If multiple users want to access the system, there are huge problems in case you want to revoke the access of someone. Namely, a new key might have to be chosen and distributed to the specific users. Afterwards, the whole hard disk might have to be reencrypted.
On Linux there exists LUKS, the Linux Unified Key Setup. Among other things, LUKS hides the master passphrase behind an interface allowing seven keys to be set independently. This also allows for a single "master" passphrase to be changed without having to reencrypt the whole medium.
By using a special boot procedure, for example by booting from an certain USB stick that is assumed to be uncompromisable, we get a system that is safe[2]. It can only be accessed by people knowing a passphrase.
But seven individual passphrases implies that only seven individual users are allowed to use the machine physically, which is a problem in theory.
IIRC, there exists another problem on LUKS: Every passphrase is allowed to delete any other one or add new ones. It is even allowed to delete all key slots, rendering all data inaccessible until the cipher can be broken (economically). In other words, it is impossible to enforce a user management policy on this level because of the lack of any suitable mechanism.
The real problem however is that everyone who knows any passphrase has access to all data on the system. For someone knowing a passphrase, the data is as accessible as a regular hard disk is for regular people. In other words, a single user can compromise the entire system and everyones data[3].
Again, since the system itself can be compromised, an individual encrypted storage makes it only harder for attackers, but can't prevent anything reliably. If it was used, checking the compromisable part of the system[4] before handing execution to it seems to be very costly, but would solve the issue. However, sharing data between users is not possible in a space-efficient manner and publishing new modifications is cumbersome and very inelegant.
Conclusion
Encryption on current systems is intrinsically non-multiuser. Either it applies only to single users, or everyone is permitted to compromise the system, or it is hella slow and renders user interactions unusable.
A new encryption mechanism is needed that works on the basis of objects instead of complete partitions, and allows objects to be shared securely between a dynamic set of users.
Comment
In other words, obviously the initial creator has the capability to access and modify the object. She should now be able to pass (a copy of) this capability to other users, which gain access to the resource by using exactly this reference.
Sounds to me like the capability security model on steroids.
- As already implied, this claim is false. Unless we're talking about a very rudimentary concept of multi-userness. But this is not the point of this post.
- At least as long as it is turned off.
- It currently seems to me that this is only possible with intent, though. However, in case of (b) it might be possible to force such intent onto single users.
- Which is essentially the current install of the OS.
The Squeak VM is Broken
SqueakIsAnInsultToSmalltalk and conceptually broken, as I explained in that post. There are more flaws in its concept, but I think I already said enough. Let's focus on its implementation.
That the VM forces users to use a GUI and that it segfaults occasionally, despite being "mathematically perfect C code" as Alan Key said at OOPSLA97[1], was already mentioned. I just stepped over additional information. Squeak is part of Gentoo GNU/Linux's Portage tree (the package repository), but will be removed because of security issues[2]. Turns out the developers of the VM jammed several libraries directly into their own project -- most of them without changes to the codebase. I doubt that this had to be neccessary.
This approach is considered bad even by *nix people. It violates all principles of modular systems, has a severe impact on software maintenance, disables users from controlling which software (versions) to install, smells of Duplicate Code, and whatnot. Additionally, it increases compile time and disk space usage without providing any benefit.
As a result, the Squeak VM has joyfully imported several security issues from the projects it jammed into its own source directory. If the authors had paid attention to some concepts of software engineering (yes, even *nix has a few of them, probably more than the Squeak VM), vulnerable packages would've automatically been updated on the next system update. And if Squeak would've depended on a specific version, the package manager would've directly reported the resulting problems to the user. In any case, Squeak itsself would not have been an issue.
That's what you get for disregarding basic software engineering principles. Glad that somebody found out.
References
- I strongly recommend watching this talk, titled "The Computer Revolution hasn't happened yet". It's somewhere on the net. Try starting there: http://c2.com/cgi/wiki/?AlanKay
- http://bugs.gentoo.org/show_bug.cgi?id=247363
On Debian
The Debian hackers have recently proven how serious they are about their expertise[1]. I have to mention that they also focus strongly on interaction design. For example: the Debian installer.
If your disk is encrypted, Debian knows what to do: Overwriting your partition encryption headers so that your keys and data are lost forever[2]. And, of course, Debian installer knows that you want this even on non-system partitions for which you provided the old passphrase and did not select "kill my data". Since Debian just knows what you want it does not need -- and, in fact, will not -- ask or print a warning or any kind of information.
This bug has been reported over two years ago[3]
and is still not fixed. Well, real hackers keep
backups anyway and its not like the system is
intended for people that dare to use software
without wanting to know how it works in detail.
Which, in fact, is a necessary
hackwould be a good idea on
traditional systems, considering their
fundamentally broken security concept.
Damn that culture.
References
Sucurity Hole
It seems that the use of a single account (that is regularly in contact with the outside) as primary account is fairly widespread. This account seems to be often allowed to log into root by running su.
This is a very dumb idea. Typing the passphrase for root into a potentially compromised system environment is about as secure as working as root directly.
Let's just assume that an application had a security hole and someone tampered with your environment. Since traditional operating systems use the broken concept of access control lists instead of the capability security model, this is not hard to imagine. Run the following line, and then run su.
alias su='echo -n "Password: "; read -s PASS; echo; echo "Hello $YOUR_NAME,"; echo "You have been hacked."; echo "Password was \"$PASS\"."; echo'
The su you're calling might always be a trojan. You might not notice until it's too late.
If you want to do something as root, switch to a virtual console. Since the login screen might not be the login screen but a phishy process, press CTRL + ALT + SYSRQ + k to kill it and force a reload of the real login screen.
Security is overrated
According to Linus Torvalds, fixing normal bugs is way more important than fixing a security hole, just because there's a lot more of them.
Oh, yes, of course...
This blog, plock, and python distutils madness
Over the past few years I've learned quite a bit. Most of it boils down to criticism on traditional software because of insecurity, low usability, missing concepts and consistency, elitism and various other ills. Add a couple of program or operating system crashing bugs to the already large list of pitfalls and the only thing you can rely on is that you will primarily be fighting against the system instead of using it to get work done.
This blog is primarily intended to document my experience with such software. The goal is to not only criticize an isolated piece of software because it is somehow "weird" or "buggy" but to also look at the whole picture and to analyze the causes.
Traditional operating systems are obsolete -- and so is third party software that sticks to those standards or even worsens them.
I'm still on my way to (re)learn software and operating system design -- Unix and Windows hell has ruined so much. So this blog is also about the stuff I'm learning; about ideas, concepts or even projects that could lead to software that is user-friendly, more flexible and powerful, and reliable.
The software I'm using is plock (git://r0q.ath.cx/plock.git). On installing it, I've been bitten by another one of the bugs I described above.
I successfully executed setup.py, an installer of Python's distutils. But on running plock, I got "no module named plock". Turns out python's distutils will naively install the software with roots current umask. Publicly installing data using private permissions is a really good idea.
The default umask on a "secure" operating system like GNU is 022, meaning everyone can read root's files if the chmod is not changed after or on creation. But if you're sane, you might want to change it to 077, denying access for everyone but the owner. This should, of course, not affect software that is installed system-wide.
To top off that dumbness, python prints an error message that is just wrong. The module is there, but not accessible. 404 != 403.
It seems that not many care for the umask defaulting to insecure, otherwise this bug in python's distutils should have been noticed prior release.
You might want to check out the archive of posts tagged "security".