The motivation for this post is the general lack of security permeating the services we use and the governments that are supposed to serve us.
The basic form of security on the Internet comes with your browser. Transport Layer Security scrambles your communication with a web service. This scrambling prevents governments, eavesdroppers, and aliens from listening while you access a bank or e-mail.
Many sites lack TLS support. It takes work to add, and it only gets added where necessary. That uncovers a basic point about security, that secure means protection equal to or greater than the risk. You probably wear clothes, at least sometimes, for protection from the elements. But you dress to the elements. If you will venture into a toxic area, you don a hazmat suit.
If you view this blog, assuming I don’t write anything obscene in your jurisdiction, you probably don’t care if those third parties know you accessed it. But for services with private data, you do care. Services should protect their important data first, and other parts only if needed or desired.
Look to the Firefox Sync service. The Firefox Sync service (Mozilla Wiki: Services: Sync), which allows users of the popular Mozilla Firefox web browser to store copies of their critical data (bookmarks, history, passwords etc.) in a service for copying between different computers and devices.
The architecture of Sync ensures that any time the risk of the data increases, the security increases to match. That’s just once, when it leaves your controlled device. Before upload, your browser encrypts the data, making it as impossible for Mozilla to access it as for any third party.
Compare that with a popular file storage service, Dropbox, which also uses encryption to secure your data. Quoting from Dropbox: Terms: Information Sharing and Disclosure: Compliance with Laws and Law Enforcement Requests; Protection of Dropbox’s Rights (emphasis added):
We may disclose […] when we have a good faith belief that disclosure is […] to (a) comply with a law […]; (b) protect the safety of any person […]; (c) prevent fraud or abuse of Dropbox or its users; or (d) to protect Dropbox’s property rights. If we provide your Dropbox files to a law enforcement agency as set forth above, we will remove Dropbox’s encryption from the files before providing them to law enforcement. However, Dropbox will not be able to decrypt any files that you encrypted prior to storing them on Dropbox.
The second emphasized portion surprises merely because Dropbox possesses the capacity to strip the encryption off of the data. While the last sentence serves to tell the user, “you can roll your own,” that strategy does not seem particularly effective at guaranteeing privacy. Sync’s method, on the other hand, leaves them powerless to decrypt the data (even if you need them to (eg, if you lose your secure key)).
Also compare the architecture of Sync to that of Google Gmail. A web-based e-mail service, Gmail uses TLS to keep your session of working with mail secure, but makes no claim to encrypt the data, and certainly not as it leaves your device.
Unlike Dropbox, which merely possesses the ability to decrypt the files, Gmail needs the plain text of the mail, as it advertises based on the content. While understandable, that business model does not necessarily benefit the user of the service. Again, you may DIY encrypt your mail, but most wouldn’t know where to begin.
Before moving on from Gmail and Sync to another topic, something worth noting (from Gmail Help: Accessing a deceased person’s mail, emphasis from original):
If an individual has passed away and you need access to the contents of his or her email account, in rare cases we may be able to provide the Gmail account content to an authorized representative of the deceased user. We extend our condolences and appreciate your patience and understanding throughout this process.
Their process includes a lot of legal documents and obtaining a court order among other hurdles. Compare that to a process Sync would need, which would require not only asking Sync for the data, but having access to a key that they do not know. If the deceased did not plan for disclosing such keys, consider that data lost until such time as computers may crack it (likely a long while).
Law enforcement and other legal processes sometimes require the disclosure of data from these services. For Sync, they receive a blob of data that they cannot read without the key. For Gmail and Dropbox, they get the actual data, ready to index and use.
The problems of government abuse weave through human history, and we should take them seriously. The first emphasized portion of the quotation from the Dropbox terms makes it clear that they do not need to prove a law enforcement request valid in order to comply.
Indeed, searching the web for information on how to verify the authenticity of law enforcement actions shows very little of use.
The American Civil Liberties Union (ACLU) writes (via ACLU: National Security: Surveillance Under the USA PATRIOT Act):
The FBI does not even have to show a reasonable suspicion that the records are related to criminal activity, much less the requirement for “probable cause” that is listed in the Fourth Amendment to the Constitution. All the government needs to do is make the broad assertion that the request is related to an ongoing terrorism or foreign intelligence investigation.
But, let’s modify that quote a little:
The [alleged government representative] […] needs to […] make the broad assertion that the request is related to an ongoing terrorism or foreign intelligence investigation.
The main change here underlines the possibility of impersonated government actions. Even if the individuals involved in a so-called law enforcement request do belong to the organizations, trusting their actions requires verification that currently does not exist.
I found a quote in a document distributed by the US Department of justice (US Department of Justice: Office of Justice Programs: Office for Victims of Crime: PDF: First Response to Victims of Crime: Tips on Responding to Victims With Blindness or Vision Impairment):
Tell victims your name, badge number, and the telephone number of
your dispatcher when responding to victims who are alone, and support
them in verifying your identity.
Note that applies only to victims, and vision-impaired ones at that. The verification process lacks any vigor, to boot. Under most circumstances, though, the merely appearing as a member of a law enforcement organization serves as equivalent to proof.
If you want to verify a government document (eg, a notice for jury duty), good luck. You can call the number provided, but they provide no chain of custody or proof. No cryptographic signature.
If served with a warrant, they provide no mechanism for verifying it, not only verifying the warrant’s registration with the claimed organization, but that the process that produced it represents an authorized, valid investigation.
We rely on some vague notion of trust alone.
The other path represents real security. The other path requires far more diligence, but it includes some emergent properties that make it worthwhile. These properties include a natural defense to corruption via feedback loops that erode bad law much faster and reinforce good ones.
Again, look at Sync. It makes you plan for if and how your estate may access your browser data. Look at the law enforcement request, where you retain control over your data, and some government agent acting under color of authority cannot ship your data to some foreign government or corporation.
A properly built online banking and payment system would preclude the possibility of unauthorized access, because a payment would not produce any data that could be used nefariously. A payment would simply be a one-time code for making a payment, just like a request to download a webpage can contain no identifiable information other than the IP address and the page requested.
Logging into your bank would give you a view of your account, but modifications (such as bill payment or fund transfer) would require several steps, with varying security, to preclude tampering. These steps use properties of known, secure handshakes, designed to thwart attacks.
The basic process of a payment:
- You tell a web store you wish to purchase.
- It prompts you for delivery information.
- You securely visit the postal service (or via some other mechanism prescribed) to obtain a secure hash for delivery information.
- You provide that to the website, which verifies the validity without knowing that location itself.
- The store prompts for payment information.
- You securely visit the bank service (or via some other mechanism prescribed) to obtain a secure hash for payment information.
- You provide it to the website, which again verifies the validity without knowing the bank account/credit account itself.
That may not be the exact process, but something similar could occur and limit the information leakage. Similar processes should work for a variety of transactions (again, warrants and other legal processes, web services, etc.). This does not merely protect you, but it protects the services as well (both their reputation and liability), as if a security breach occurs, the attackers only get a bunch of hashes they cannot do anything with.
Thanks, I know this ran long and still needs clarification and better development. Feel free to ask questions or give feedback.