Authentication, VPN "Privacy" Networks, & Tokens - rethinking Darknet Access Control
- Why do we do things this way, and not that way... indeed, why do we do some things at all?
One of the luxuries of building a next-generation privacy network from a blank slate is the opportunity to radically reevaluate previous assumptions about how to do things... and about what needs to be done, or not done, at all. This isn't the kind of luxury available via incremental changes; it requires that blank canvas on which to create from scratch. It's the core reason why the cryptostorm team has chosen to walk away from the old Cryptocloud VPN network and create something entirely new.
When we made this decision, we had a list of things we knew we wanted to improve - and an equally large list of things we knew had to be changed to protect against new-generation threats (BEAST/CRIME SSL attacks, the NSA's PRISM program, the XKeyscore interception toolkit, etc.). We also had some deeper intuition that one area, in particular, was ripe for radical overhaul: network authentication.
Sounds boring, doesn't it? Actually, it's not - and here's why...
"Can I Use the Network... Please?"
Secure networks, private networks, "darknets," heck even the oldster term WANs all refer to networks-within-networks. Once we have access to the internet itself, we can send and receive packets with others who are also using the same TCP/IP protocols. But if we want extra security, we're going to be looking for a network-within-the-network - call it what you will, they're all essentially the same structural creations. Partition off some space (virtual, not physical), add on some cryptographic goodies, design in clever stuff relating to routing data and/or anti-traffic-analysis methodologies... and you've got yourself your standard-issue darknet of whatever particular flavour.
Right off the bat, there's a core decision to make: does the darknet allow anyone to use it, or is it limited access? Limiting access might be because we don't want some class of users participating - but, far more often it's a question of network resources. Managing network resources takes us in one of two possible, diametrically opposed directions...
On the one hand, we might have an "open access darknet" such as the Tor Project. You don't need a secret handshake to use it - anyone can join. You don't have to buy credits, or a subscription, or anything whatsoever to route stuff through Tor. As such, there's fundamentally no question of network authentication - you show up, you ask to route data through Tor, and Tor routes your data.
On the other hand, there's access-limited darknets - the classic examples in today's market are "VPN companies." They run a series of exit nodes and encrypt traffic between client computers and those exit nodes (alot like Tor, in that regard), except you have to have a secret handshake to make use of the networks. Some are "free," which is to say advertising supported - but even those, you need to sign up, register, log in, and so on. The rest are paid: you pay money for a subscription, and that subscription buys you access to the network. No subscription, no access. Pretty simple stuff.
Now, obviously the big issue here is network provisioning: the open access Tor network is always struggling with infrastructure: since they rely on donated network resources, there's a constant struggle to keep enough donated goodies available to serve everyone who wants to use the Tor network. Worse, the more capacity they manage to finagle out of donors, the more folks show up to make use of the network - the better the network runs, the more people use it and the slower it will inevitably become! Tor's success ends up making the job of their team harder, because they need more donations to keep things running smoothly. In practical terms, Tor is - and always will be - resource constrained. That means, in simple terms, it's slow. Open access all but guarantees that'll be the case.
In contrast limited access networks limit access and by doing so can ensure that resources/infrastructure grow fast enough to provide good service levels. Well, that's the theory anyway - an awful lot of limited access networks still have piss-poor performance. But, in theory, the limiting of access means that there's money available to buy infrastructure and thus keep the network running smoothly as it grows. The downside is you end up with some kind of authentication system, by definition, which serves to limit access to the network.
So far, this is all tediously boring. But bear with us, the good stuff is coming up...
"Go Away, You're Not Allowed!"
Let's stick to limited-access networks, the kind that require some kind of authentication system. And let's stick to "VPN services," which is to say private encrypted networks that are designed to provide subscription-based service to "consumers" (as opposed to businesses - an odd term, but that's what gets used in English, alas). Essentially everyone in the "VPN industry" uses tools - VPN tools - to handle the encrypted connections within their network. Just as importantly, everyone uses these same VPN tools to handle network authentication. Makes sense, right?
Actually, not at all.
Step back from things for a minute, if you will: Virtual Private Network - VPN - tools were engineered and created to facilitate a very clear and very well-defined use-case scenario. That is a "mobile employee" - someone working from home, or on the road - who wants to connect to a corporate network and make use of stuff on that network. Name the protocol: PPTP, IPSec, OpenVPN... they were all created with this corporate-worker use scenario in mind. Sure, they can do other things - connect two servers on the internet, for example - but the basic assumption has always been that of the remote worker and the home office.
And in that scenario, if you're the sysadmin running that office network, you've got a couple of really big security issues to think about. One, you want to make sure the traffic back and forth with your remote workers - the packets going out over the "public internet" - is encrypted and secure, so that someone can't sit there bump-on-the-wire style and read your Valuable Corporate Secrets as they go whipping by. Two, you want to make sure that the person connecting to the network is authorized to connect to the network - currently, in realtime. You want to make sure that Janet is Janet - the sales genius Janet, not someone pretending to be her to steal her sales leads from the customer database. And you want to make sure that, if Janet is fired, her network access can be easily and irreversibly revoked - right now.
Still boring, right? Yep, but if you're reading closely it's likely you've already had the "AHA!" moment. Let's spell it out...
Using these VPN tools - and their implicit assumptions about network authentication - for controlling darknet access is a bit of square peg in round hole. More than a bit, really. In fact, the darknet use-case scenario is pretty damned different. In a darknet, there's no "secret network resources" you're trying to protect; instead, it's really a pass-through network that doesn't actually host anything (Tor "hidden services" are a bit different... but not really). There's no Corporate Secrets being protected.
And there's no pressing issue about ensuring that Janet isn't "impersonating" Janet, in precise terms. So long as someone's paid for access to the network, do you care if it's Janet... or James, or Jackie? Not so much, at heart, since none of them gets individualized access to specific network-based resources... because there are no network-based resources! It's all just pass-thru.
And there's no scenario of Janet suddenly being fired, and thus kicked off the network. Sure, some "privacy" companies have Terms of Service that go on for pages, and pages, and pages: if you "violate" them, they say they can immediately revoke your network access - fire you, basically. But if you're paying a "privacy" service to keep you private and that service is spying on you to see if you're following their rules... well, you're already off in the brambles and need to fix that first. Apart from that, you pays your subscription and you gets your access. Sure, if you don't pay to renew, your subscription runs out - but that's not like Janet suddenly (and unexpectedly) being fired, and thus being booted off the network.
Yeah, you can see where this is going now...
"Don't Tell Me Who You Are... I Don't Need To Know!"
What's the best way to keep a secret? Don't ever tell anyone. Done - secret is safe.
The big benefit of Tor - of any open access network - is that there's no reason for the network to be poking it's nose into who you are, as in specifically what real-life human you are, where you live, what your billing address is, and all that. Open access: don't need to know that. And, indeed, Tor doesn't ask - goes to some lengths to be sure it cannot, in fact, know who you are. Which really increases the security of things, from the network user's perspective: it's a great way to keep a secret, because you never tell anyone who you are in the first place.
"VPN service" companies - limited access darknets - don't work like that. They demand to know who you are... since they are limiting your access, based on whether you've paid or not. Then, they promise not to tell anyone who you are - except if they cross their fingers behind their backs, and say they will if they really feel like it. Or they say they won't, and just plain lie - telling people anyway. Or they screw up, and allow themselves to be pwned... thus spilling secrets about customer identity. It's an intractable problem. As the Grugq said recently in a discussion with us on Twitter...
Nope, none whatsoever.
I'm Not An Office Drone - I'm An Internet Free Spirit
Yeah, the network needs to know that you're a paid-current subscriber. But that is not the same thing as knowing your identity - not at all. You're not Janet, working from the road on your big sales crusade - you're using a darknet to stay secure & private, ffs! The details of your financial transaction have absolutely nothing to do with your ability to access the network, or not - apart from a binary choice between whether access is allowed, or not.
If you look at how "VPN services" authenticate people for network use, that's not at all how things work. They all - each one of the dozens (hundreds?) of me-too VPN companies - simply grab the built-in authentication widgets of VPN protocols, and off you go. Those widgets, recall, were designed with Janet in mind... and as such they go to great lengths to be very sure that you are who you say you are. Authentication, old-style: prove you're Janet, or you can't use our network.
No. No, no, no, no, no! That's all wrong.
This is not how it should be done. Not at all.
"Ask Us No Questions, We'll Tell You No Lies..."
We don't want to make it seem like we're exempt in these criticisms, just to be clear. The old Cryptocloud VPN network used email address as network ID (!!) - which pretty much closes the circle and shows that all of us got this wrong, right from the beginning. Indeed, back in 2008 when Cryptocloud helped create the "VPN industry" as it exists today, we actually made the decision to use full-scale certificate-based, public-key, DH-enabled client authentication as the basis for our network connection procedure. Seemed like a good idea at the time; heck, read the OpenVPN manuals & this is what they have to say about the subject:
More security is good, right? Well, yes... but that assume you're Janet. Alot of that "security" that certificate-based authentication implements is actually making sure that you are who you say you are... which is exactly what you don't want to tell a darknet in the first place.--client-cert-not-required
Don't require client certificate, client will authenticate using username/password only. Be aware that using this directive is less secure than requiring certificates from all clients.
Eliminate the Middleman
Man In The Middle (MiTM) attacks are a real, verified, seen-in-the-wild risk to users of VPN-based network privacy services. On the surface of things, you might think that doing a big, certificate-based authentication to the network will help protect against MiTM... and you'd be partially right.
Specifically, the scenario we actually want to protect against in darknet authentication is that an attacker manages to convince clients connecting to the network that they're connecting to the network... when, in fact, they're connecting to the middleman. This would allow the middleman to capture plaintext network traffic, breaking security. A subsidiary threat vector is a MiTM attack that targets an existing secure session, slipping into the middle of it without either side knowing it's happened (for technical reasons, this tends to be substantially more difficult than a "spoof" of the original session setup).
Protecting against these actual threat vectors requires that the server prove it's legitimate- the attacker would have to fake that he was the secure network server, and trick the client into connecting. The reverse scenario - tricking the server into believing a client is a "real" client when in fact it's not doesn't actually make any sense at all. Worst-case - and it's not very "worst" - is that someone tricks the network into allowing access without paying for access. No security is broken, and no network user data is at risk. So, there's no use confirming that a client is a specific client with a specific identity - it adds no security to anything at all, and actually decreases privacy in the macro sense.
We do want to ensure that a client doesn't "switch identities" mid-session, as that would allow a hijacker to take over a session and perhaps get access to private data. However, doing so is a different cryptographic challenge than verifying a specific identity as it exists in some remote database. Fortunately, ensuring that mid-sessions switches doesn't happen is straightforward using modern, well-tested cryptographic tools.
Protecting against the well-documented attack vector of MITM doesn't require client identity authentication, and doesn't make the network any more secure for actual customers.
Network Tokens - The Future of Darknet Authentication
In hindsight, the right way to do this is both obvious and entirely different from the way it's currently done in the "VPN industry." The right way to do it is via what we call "Network Tokens," or NTs for short. NTs are cryptographically-generated passkeys that encode in their mathematical structure only the information that confirms the NT is valid for a certain defined period of time. That's it.
NTs replace "username," password, email address... all the other left-over flotsam & jetsam of Janet's work-from-home use scenario. NTs are the handshake that lets the darknet know a given network session is authorized - and that's all it lets the network know.
Finally, NTs have no explicit connection to any financial or billing system. As operators of the darknet, cryptostorm need not know that information. We don't want to know, in fact. How you, as a customer of the network, know that cryptostorm isn't making that connection (between NTs and your financial/payment info)? Simple: buy the NT from someone other than us.
Because the most secure model for darknet administration fully decouples payment data from network authentication (more formally, it ensures there is a non-reversible/one-way transform of the former into the latter), the right way to do things is for someone other than cryptostorm to sell the NTs. So that's what we've done.
NTs will be provided, in bulk, to resellers who then distribute them to folks for use on the network itself. That way, cryptostorm simply doesn't know who purchases which NT - we can't, as those actual sales are done by the reselling partners rather than us. Sure, we might be able to figure out that a given NT was part of a given batch sent over to a given reselling partner... but that's it. We could call up the reseller and demand they tell us who bought a specific NT - but good resellers will be teams that are trusted not to tell us, not to keep those data in the first place, or both.
Trust - But Verify
It's a different way of thinking about - and implementing - a private network. Using NTs goes against the assumption that doing a fancy, sophisticated, prove-who-you-really-are authentication makes things more secure for network users. We've been thinking about this question for years, and we've been convinced for some time that there's a better way to do things. But it's not been so obvious how to do it, until recently. In truth, some of the final Eureka momentum has come from watching how the bitcoin "blockchain" model scales in the wild.
Finally, this year, we started to see how to do it better.
As we helped work on the "torsploit" analysis & studied the ways in which certain attackers (<cough>NSA<cough>) are going after Tor's security strong points, we realised that there's a way to capture a big chunk of the extra privacy afforded by open access darknet authentication... if you're willing to throw out all the old assumptions that have sat at the core of the "VPN industry" since 2007.
So we threw it all out, and started with a blank piece of paper.
The result is Network Tokens. Never again do customers of a secure network need to make a trade-off between genuine anonymity, and full network performance. Now, it's possible to have both - without sacrificing either. All it takes is the willingness to reconsider everything you've previously assumed, re-evaluate what's possible, & rebuild a new network from the ground up.
As we move from this pre-launch phase into full production status, prior Cryptocloud customers will receive their NTs for access to the new darknet. Shortly thereafter, folks who have added their names to the queue for network access will be provided with links to resellers who have NTs available for sale; they're limited based on network resources, so it's first-come, first-served.
Over time, we'll be doing our best to ensure the NT model of network access is as elegant, customer-friendly, and streamlined as it can possibly be. We don't accept the need to trade off elegance for real security; indeed, we know that sometimes the two go hand-in-glove... just like with the NT model itself. As we fine-tune the NT model, we know our customers will continue to help us find ways to make things better.
the cryptostorm darknet
There's no such thing as a perfect system. There's always the possibility to improve, and what was the best thinking - and best implementation - of years past is often left behind by new, more effective ways of getting things done.
Network Tokens are one way that the cryptostorm team is forging a path forward to more secure, more elegant, more robust network privacy service. We're eager to see how other security experts take the general concept and refine, expand, and evolve it further - it's a collaborative process, and we've always been part of the community's collective work towards better tools for protection against all forms of surveillance threats online.
Now, more than ever, it's time for seriously forward-focussed approaches to network privacy service. Relying on old tools, old models, and old assumptions in today's post-Snowden world just won't do.
- ~ cryptostorm_team
I have a couple questions concerning tokens, and so far I've not seen them asked.
