I love this. These projects almost certainly ultimately fail, get laughed at, and then end up educating us anyway, whether for what to do or what not to do. I expect I'll probably see some hilarious things from it early on, laugh at it's idealism and mistakes, and in 10 years I'll be using tech designed by it's apostles.
We all talk about how silly it is and has been for years, while simultaneously extolling the values behind the development ideas that Plan 9 follows, and the good practices it teaches in regards to OS development.
So you're saying its creators think it's silly? It has a sense of humor, apparently, but I don't think that's the sense of "Plan 9 is silly" the GP is asking about, or even related to it.
Of course, we've been told that a clean-slate design is doomed to failure. But we believe that all traditional OSs have failed and are unfixable. If this is the case, there really is no alternative to clean slate.
That was my immediate thought, too, and I spent a good ten minutes on their site trying to figure out the connection and determine whether I was correct or not.
"Security" is an invisible quality, by which I mean it cannot be easily observed and because of that it cannot be easily compared and because of that is not going to drive adoption.
This is in contrast to visible qualities: price, performance, availability of the source code and its licensing terms, size of the ecosystem (number of applications for the OS, number of books, articles, conferences, programmers who know how to program for it) etc.
How exactly will you demonstrate that Ethos is more secure than, say, OpenBSD?
I think it's more about the possibility of guarantees.
OpenBSD has un-typed IO. Typed IO gives you guarantees that un-typed IO can never give you. For starters, a number that doesn't validate properly as an Int, for instance, will simply not be able to pass through, potentially stopping if not Heartbleed then bugs like Heartbleed.
Don't you think companies and other interests would like stronger guarantees, especially when they're running applications that protect information that hackers and foreign governments and other companies would love to see?
Until it becomes difficult to work with and is perceived by someone as slowing them down, at which point someone will come up with the bright idea of typing the io channel to a suitable type for layering an untyped stream over.
This is the reason why we believe the Tao--the way--is essential to an OS. It is the programming paradigms and use, combined with OS semantics, which is the genius of UNIX.
Where does the IO typing come from? Is it some programming language? The website says that it uses C for kernel and Go for user space, neither of which are known for having advanced typing systems.
I don't think number of applications is a big deal when it comes to stuff like this. As long as it has a secure network stack and implementations of various servers for core internet infrastructure it's good enough for me. Now if you were talking about consumer grade operating systems then it would matter.
Agreed- a new, more secure OS will need other good qualities to actually market itself on.
One idea that could improve both security and the ecosystem would be a capability based design. Separating components through standard protocols/interfaces could enable something like current mobile permissions to be backed by different implementations (including virtualized/sandboxed ones), in some cases swapped out by users like commands in a shell pipeline.
I haven't seen much work in this direction; does anybody think this would or wouldn't work?
It's not always invisible when your computer or phone gets pwn'd and your email account starts sending spam, or your identity gets stolen. I think as the world becomes more technically literate, and insecure systems proliferate, security will become more and more visible. I would at least expect it to be the next competitive battlefield once usability starts settling down (as everyone figures out what does and doesn't work).
It can be partially observed by looking at the amount people in-the-know (the developers, insurance underwriters, auditors, ...) are willing to bet on the security.
The reason security will drive the adoption of a new OS is that little else will drive people away the current ones. In a future where our current architecture is being constantly exploited, then security will finally matter enough to drive us to something new.
Here's why I don't agree. This is a real conversation I had with someone about Heart Bleed:
N: So will I have to change all my passwords?
ME: Yes, you should.
N: That's a lot of work.
ME: Yes, but if you don't someone is likely to break into at least some of your accounts. At least make sure you've changed the password to your mail account, and set up two factor auth [very simplified explanation of what two factor auth involved], and check that all accounts you care about use that mail account for password recovery.
N: I'm not sure if I can be bothered.
This is a relatively technically experienced user.
It fits with other experience I've had, that security is perceived as a hassle until it's too late and then users do the bare minimum, even in the face of ongoing threats.
Corporate users might help drive adoption, but only if the cost and hassle is limited enough, and the damage of not going there is high enough.
The future will tell about Ethos' success. But I think the earlier adopters will be the tech savvy community that wants security & privacy and buys into Ethos' programming model.
This is probably going to be an unpopular position, but I think it's also important to keep in mind all the arguably beneficial things that insecure and "open not by design, but by neglect/accident/unintent" systems have brought us. Homebrew software on gaming consoles; "jailbreaking" and "rooting" phones; various other hardware/software hacks; leaks of information that have provided important information to the public (including, most ironically, the Snowden/NSA stuff.)
Would living in a world where events like Heartbleed will occasionally occur, but one where we still have the relative freedom to modify, examine, and generally "hack" our software and hardware in ways the original creators didn't approve of, be better than one of "absolute security" and highly restricted, locked-down devices controlled by corporations (and possibly the government)? I think the whole security situation has reached a point where people have to really start thinking about the tradeoffs that are happening, and realise that all this technology - as much as it can protect against external attacks and defend the users - can also be just as easily employed by others to oppress them. Once again, the infamous Ben Franklin quote comes to mind.
You raise an interesting point. However, we believe that the difficulty of securing systems makes the world less private and less free, especially as we outsource everything to third parties. A strong software base would allow us to reclaim the high ground, and empower the individual.
>The need which will drive new OS adoption is security.
Yet Microsoft XP/7/8 are arguably the most insecure operation systems, and the BSD flavors are arguably the most secure, yet have the lowest adoption rate.
People don't care about security they care about usability and simplicity.
But this is at odds with your previous observation, that BSDs have low adoption. They are vastly more simple than typical linux distros, a fact that linux users complain about when trying out a BSD system.
But security is a policy, it's something dynamic. Not static, that's why the OpenBSD moto is a silly as it gets.
Of course design matters, a system designed from groun-up to be secure but even a Linux server with properly configured kernel patchets (grsec), process accounting, iptables, IDS, etc. Can be virtually impenetrable. Same goes for OpenBSD.
Secure operating systems are not new. IIRC Vax/VMS was build from ground-up with security in mind and was deployed by the military. Then exploits security issues started popping up.
So, I read a few of the papers. I'm hoping the Ethos OS folks are on this forum, since I have a couple questions and concerns.
First, my current understanding of the OS:
Networking TL;DR: Their protocol is called MinimaLT, and it effectively replaces TCP/IP. Traffic sent through a MinmaLT channel is encrypted and MAC'ed by the OS. Each user has a public key, which gets submitted to the remote host for each MinimaLT channel. The public key identifies processes belonging to that user on both endpoints. The user can generate a new public/private key as often as once per connection to allow for anonymity. The OS maintains one channel per host-to-host tunnel, and multiplexes it across applications.
Key management TL;DR: There exists an organization-wide key directory service and ephemeral key upload service. Servers register and re-distribute their ephemeral keys to their local key upload service, which synchronizes them with the directory service. Clients connect to their local directory service to get the ephemeral keys for other servers. The system scales up by piggybacking on DNSSEC--the directory service delivers its local servers' ephemeral keys to other directory services outside the organization by embedding them in short-lived DNS records (which then get cached).
Questions:
* It's not clear to me how a server comes to trust a user's public key. Is it trust-on-first-use? If so, how does a user revoke the public key? For example, if Mal stole Alice's key, now Bob's server thinks Mal's actions are from Alice. What do Bob and Alice do then?
* It's not clear to me how the directory service and key upload service come to trust a local server. Is looks like this is something the local admin has to do manually?
Concerns:
* I'm not sure if this is more secure; in fact, I think it's less secure than SSL. The authenticity and integrity of ephemeral server public keys are backed by DNSSEC's security. So, this scheme effectively replaces a bunch of (presumably) independent TLS CAs with just one: the DNS root. You can bet the NSA has the private key.
* I don't like how the network architecture couples key distribution to name resolution, which I view as orthogonal concerns. This design puts both under the control of the same administative entity, which makes it easy for that administrative entity to trick clients into communicating with the wrong servers.
* MinimaLT isn't amenable to content caching. How does a CDN know that two ciphertexts are really e.g. the same image file? If it can tell, then the CDN can break your end-to-end encryption. If it can't tell, then the origin server can't scale.
Borando is correct. MinimaLT (our TLS replacement) will use some sort of PKI, and eventually SayI. SayI is completely distributed, and enables the relying party (the entity doing the authentication) to choose which parts of the PKI to trust. And it will scale to the Internet; efficiency has been a problem with choose-who-you-trust PKIs.
We are working to release a Research Prototype for MinimaLT, which can be used for open source prototyping while simultaneously hardening our implementation.
There are a number of projects, open source and academic which are looking at MinimaLT. Some are implementing or providing interfaces for other languages (e.g., JavaScript/Erlang). Others are analyzing the security.
Most of all, we are focused on a small, tight codebase. Everything needed for security but not one iota of extra code. This is one of the ways we are engineering MinimaLT to avoid the problems that plague TLS.
You're missing the major point: MinimaLT will initially use X.509 (since it's already deployed). A future protocol upgrade will support, if I'm not mistaken, sayI.
DNS Security (e.g. DNSCurve, DNSCrypt, or even DNSSEC) adds a second layer of security: keys are transmitted in DNS records, and server auth is done via X.509.
This means an attacker would have to break both X.509 _and_ DNS.
I'm not sure if this is more secure; in fact, I think it's less secure than SSL
I believe the above point addresses your concern. In addition, MinimaLT's Curve25519 + Salsa20-Poly1305 is superior to any ciphersuite found in TLS.
As discussed in many, many other OpenSSL related posts here in the last few days, it's becoming pretty clear that any "open-to-public" PKI system will practically be required to be built on a third-party trust system (as also discussed, PGP WOT system also reduces to a third-party trust system when it comes under attack). @jude- How else would you solve this problem if not through one or the other third party trust based PKI?
I've had an idea rattling around in my head for a while now about how this might be achieved.
* CAVEATS *
(Not directed at anyone in particular, but I always state these when I talk about security in detail).
"Security" and "trust" are fundamentally economic and social problems that sometimes (but not always) have feasible technical solutions. You can't reason about either without first considering the (human) adversaries you face, as well as the society in which your users and adversaries live. In my ideal world, for example, all systems are secure and trustworthy by default, since the people building them and interacting with them are all responsible and ethical (we sadly do not live in this world).
Paradoxically, the "easy" part of making a system secure and trustworthy is implementing the cryptographic primitives, since their correctness can be formally proven. The "hard" part is key management, since "correct" key management depends on your threat model. If you mess key management up, then it doesn't matter how well your crypto is implemented, since now your adversaries have your keys.
* THREAT MODEL *
Now that that's out of the way, let's consider threats to key distribution in the post-Snowden world. We're up against a large state-level adversary (i.e. the Mafia, the NSA, botnets) that has lots and lots of CPU cycles. The adversary can read anything on any network and store it indefinitely, and they can alter any data in-transit. They can coerce a large number of users to make all of their data readable, and they can coerce them to change their data arbitrarily. However, I'll assume that the rest of the users beyond the adversary have more computing power combined, and that the adversary cannot coerce the majority of users to reveal or alter their data. I think that both of these constraints on the adversary's power are reasonable, since external factors (like social push-back against the large-scale power abuse required to overcome these constraints) will limit the power of the adversary in practice.
Now, the problem is: given this adversary, how do two users Alice and Bob exchange and revoke public keys over the Internet? With PKI strategies, Alice and Bob both trust Charlie, who certifies Alice's and Bob's public keys. If Alice revokes her public key, she gets Charlie to vouch for a revocation notice to Bob, which Bob accepts since Charlie vouched for it.
The problem with PKI implementations today isn't Charlie per se. After all, Alice and Bob have to have some way of verifying that the each other's public keys are authentic, and since it's not feasible for them to meet in person to do this, they have to "meet in the middle" with either trust-on-first-use semantics or with one or more trusted intermediaries (CAs, web-of-trust). The problem with PKI implementations today is that our adversary can get Charlie (i.e. a TLS CA, a key server, the ISP's network, etc.) to vouch for or deliver the wrong keys and revocation notices. What's needed is a way to make it so the adversary can't coerce Charlie without receiving a HUGE public backlash each time.
To do so, we'll use a well-known blockchain as a notary for Alice and Bob's public keys. Under our threat model, it's reasonable to assume that even a state-level adversary does not have enough power (computing or coercive) to execute a 51% attack on the blockchain. To see why this is a reasonable assumption, consider what would happen if the NSA were to attack Bitcoin. If they did, everyone who invested in Bitcoin--a lot of people, some with powerful friends and lobbying groups--would be out for blood, and the NSA's power would likely be reduced by Congress or the President as part of the backlash (we might also see resignations from the NSA ranks). Moreover, the blockchain could be recovered and the offending hosts identified (the fork where the 51% attack started would be evident), making the pay-off to the NSA very small compared to its potential losses.
* KEY MANAGEMENT *
The blockchain gives me an idea for a protocol based on the Sovereign Key proposal from the EFF [1], but with two key differences (no pun intended). First, unlike traditional PKI systems, Alice generates key pairs and CSRs in advance, and publishes all of the public keys at once to one or more public locations. She uploads the URLs to the public key bundle, its cryptographic hash, and one or more user-specific identifiers to the blockchain (using a one-time-use blockchain key pair). Then, anyone can fetch her public key bundle and verify its integrity by using the blockchain as a notary, and we don't have to worry about the adversary covertly modifying the keys or identifying information after the fact.
The second key difference is that Alice manages her private keys in a way to force the adversary to use human intervention to compromise them (greatly driving up the economic and social costs of doing so). To bootstrap key distribution, Alice thinks for a while, and deduces that she is likely to encouter N private key compromises over her lifetime. She gets a trusted computer and generates N key pairs and a CSR for each one. She signs each CSR with every private key to prove their authenticity (since throughout her life, only she is expected to know them all). She puts these keys in the order she will use them over the course of her lifetime, and gives them each a sequence number (PK_1, PK_2, PK_3, etc.).
She takes the private keys and their matching CSRs and stores them in various places that are hard for the adversary to find without noticeable human involvement. Some she keeps on her devices, some she stores in an offline USB stick, some she prints out and puts in a bank vault, some she prints out and buries in a safe in her back yard, etc. She only needs to have the keypair she's currently using installed on her devices. This leverages the assumption that it's not feasible for the adversary to compromise all of her keys without forcing her to help (and thus bringing their snooping to her attention, which she'll complain about on the Internet and get the media involved). Even a state-level adversary won't be covertly digging up everyone's back yards in search of buried private keys anytime soon :)
Alice uses her keypairs in order, revoking them as they get compromised or expires (if she specifies an expiration date). When she revokes a public key, she goes and gets her offline CSR and publishes it to the blockchain.
Alice always uses the uncompromised private key with the smallest sequence number to communicate securely. Bob can easily figure out which one this by (1) fetching Alice's key list (i.e. from one of the URLs in the blockchain), (2) verifying its integrity with the blockchain's copy of its hash, and (3) scanning the blockchain for subsequent valid CSRs.
The remaining challenge is for Bob to discover which blockchain record belongs to Alice (so he can get the right key bundles). To do so, Alice includes as many user-specific identifiers in her blockchain record as possible, to bind her strongly to her key bundle.
The set of user-specific identifiers is arbitrary (I got the idea from onename.io [2]). Examples:
* a (hash, [URL list]) pair that identifies a picture of Alice holding a hand-written copy of her key bundle hash.
* Alice's TLS-secured and DNSSEC-secured domain name
* Alice's bitcoin wallet, which has a transaction including her key bundle hash
* Alice's twitter feed, which contains her key bundle hash
* A signature of the key bundle using a private key from a separate PKI (which Bob has the public key for)
* her email address, so you can ask her for her key bundle hash
* a link to a press conference that features a picture of her doing something she's well known for
* cryptographic signatures from other people or CAs
* usernames on other services, along with content that includes the hash
* an OpenID identity URL, which contains her key bundle hash
There is space here for TOFU, CA, and WOT semantics, allowing Alice and Bob multiple ways to authenticate (some automatic, some manual). Alice can include her TLS certificate to authenticate to Bob via the existing TLS CA infrastructure. If Alice and Bob prefer WOT, they can authenticate through a chain of individuals between them. If Alice and Bob want manually authenticate with TOFU (i.e. through their web browsers), the browser will load a dosier of the other principal using the blockchain record.
Once Bob has decided to accept Alice's key bundle hash based on the identifying information, then Bob can communicate with Alice securely. I intentionally avoid mandating an authentication mechanism, because this is an application-specific choice based on what the user will trust the application with and how secure the application needs to be.
1) The government can be trusted to mitigate its own attacks because bitcoin users get angry ("the NSA's power would likely be reduced by Congress or the President"). This is patently ridiculous; government security agencies do not become less powerful over time.
2) Alice can predict the future. ("Alice thinks for a while, and deduces that she is likely to encouter N private key compromises over her lifetime") Similarly, this is... unreliable at best, uttery ridiculous as phrased.
The final, and fatal, problem with this plan is that Alice's bindings to 'her' blockchain are subject to false flag operations / account compromises (OpenID, email, etc), or else they are relying on other PKI schemes (DNSSEC, TLS), which just pushes the problem back to the starting gate.
1) First, it doesn't particularly matter as long as they are not powerful enough to execute a 51% attack. Second, government security agencies (or rather, the laws granting them their powers) do get rolled back in practice once they're found to be unconstitutional or supremely unpopular.
A few examples off the top of my head:
* The US doesn't intern Japanese-Americans anymore, but did for "national security" reasons during WWII.
* The US has suspended and later restored habeas corpus during the Civil War, Reconstruction, colonization of the Philippines, and WWII (again, due to "national security").
* The US passed and later repealed (or allowed the expiration of) the Alien and Sedition Acts (also "national security").
* The SCOTUS has limited the powers granted by the Espionage Act of 1917 over the course of the 20th century (particularly w.r.t. The Pentagon Papers).
I personally think if the NSA started to attack its own citizens en masse via a 51% attack, the citizens and their representatives would soon look to curtail its power to do so (especially since there's money involved). Maybe I'm too optimistic, but time will tell.
2) Alice's goal is to make it so that it's not cost-effective for her adversary to compromise all of her private keys. She must estimate how much time and money her adversary is willing to spend, and then devise a way of storing her offline keys so that its not worth their while to compromise them. Effectively, she is insuring her keys against theft, just as she might insure another easily-stolen valuable asset. This means Alice can bring to bear the whole field of actuarial science ("predicting the future" as you call it) to find the best way to keep her keys safe.
The final, and fatal, problem with this plan is that Alice's bindings to 'her' blockchain are subject to false flag operations / account compromises (OpenID, email, etc), or else they are relying on other PKI schemes (DNSSEC, TLS), which just pushes the problem back to the starting gate.
Regarding account compromises, the public key bundle can only be written once, and Alice has (presumably) insured her private keys. This limits the effectiveness of false flag operations--once Alice (or whatever username she claims) puts a key bundle, no one else can do so without being caught and rejected.
Before addressing full compromises, consider this thought experiment: if you were to one day meet me in person, how would you know it was me? Sure, I could say "I am jude- from Hacker News" and show you my GitHub page, my government proofs of identity, my fingerprints, etc. But, that could all be forged, and pretty easily by the likes of the NSA. Proving that I am who I say that I am will ultimately require a leap of faith on your part--there has to be some information I can show you that will convince you that I am who I say that I am (i.e. you believe the information I present would be infeasible for an imposter to forge--you can apply actuarial science to estimate the costs and payoffs to an impostor, as well as likelihoods and conditional probabilities that an impostor would want to spoof you, and so on).
Now, maybe the actuaries got it wrong, and maybe it became feasible for Alice's adversaries to compromise all of her keys, and maybe that happens. In general, there are one of three solutions:
* Alice uses a trusted 3rd party to vouch for her over the impostor (undesirable as you say, since this is DNSSEC and TLS all over again).
* Alice posts all of the CSRs she generated earlier thereby revoking the impostor's identity, and then races and beats the impostor to re-generating the identity/keybundle. Not always possible, since Alice may have lost the CSRs, and/or Alice might lose the race. This leads to option 3:
* Alice abandons the old identity and builds a new one.
Granted, option 3 is messy and hard--a lot of people would be in a world of hurt if they lost their Facebook accounts, for example. However, this is why you have lots of offline keys stored in lots of different places in the first place--to avoid this situation altogether. Since we want to avoid centralized 3rd parties, I don't see any other way than to do our best to insure against total key compromises.
Perhaps one extension to the protocol would be to devise a secure way for Alice to generate more public keys, if she still retains enough private keys...
Definitely, we are starting to open it up, encourage open source developers to get involve, and to encourage wide-spread use. If you are interested in getting involved, I'd like to hear from you.
When we do release, we want the software to represent both the Tao of Ethos and to be accessible for experimentation. We are working assiduously towards that goal.
Well they kinda need to get grants so keeping it a little closed up for publishing research isn't necessarily bad. It does mention that they plan to open it up.
Turn an incredibly complex operation into a simple one? Assuming we could make it sufficiently simple, what do you do when someone needs a new simple feature like pinging?
> we need multiple independent quality implementations of that API
Where are all the experienced cryptographers waiting in the wings to reinvent your wheel five times?
> if one turns out to be crap, people can switch to a better one in a matter of hours
After the exploit has been found, after two years, to switch to something which might also have the same flaw?
Today's software requires constant patches to "stay" secure. If you stop patching your OpenSSL or your Windows XP, its security will degrade -- but the software is the same; all that's changed is some hacker was able to construct an MS Paint file that executes arbitrary code, or some other ridiculous nonsense.
Large software systems will always have bugs and be difficult to understand in their entirety, but they could be made orders of magnitude easier to secure by not giving every line of code the potential to compromise the system.
Writing up the design principals of Ethos is one of my goals this summer. The short description is:
(1) Strong security services (authentication, authorization, encryption, isolation)
(2) Higher level, less error prone semantics for all OS interaction.
(3) Security guarantees derived from system layering
(4) Highly composable semantics
Note that only (1) deals with security-specific code. The rest deals with overall code quality.
The research papers are there. There is even a paper reading group. The project appears to be the synthesis of a few "attractive" design choices, combined into one. So each of those things has its own paper(s).
Insight ETHOS: On Object-Orientation in Operating Systems (1992)
http://e-collection.library.ethz.ch/eserv/eth:38713/eth-3871...