The EFF recently proposed to fix a major problem in the Internet’s Public Key infrastructure:
One of the main problems with the current PKI model is the lack of control over CAs and their subsidiaries. There are literally hundreds of organizations spread around the world that are allowed to issue certificates for any domain name and some of them are operated by governments that practice Internet surveillance and censorship.
Worth reading.
My previous post about Apple security focused on an article by Wil Shipley wherein he discussed signing apps written for Mac OS X with certificates. One of Shipley’s main points was that the two primary mechanisms for enforcing security on the Mac App store (sandboxing and auditing) are fundamentally flawed. Now we have a great example of how auditing fails:
Miller, a former NSA analyst who now works as a researcher with consultancy Accuvant, created a proof-of-concept app called Instastock to show the vulnerability. The simple program appears to merely list stock tickers, but also communicates with a server in Miller’s house in St. Louis, pulling down and executing whatever new commands he wants. In the video above, he demonstrates it reading an iPhone’s files and making the phone vibrate. Miller applied for Instastock’s inclusion in the App Store and Apple approved the booby-trapped app.
The rest of that article includes more details on the code signing flaw Miller exploited, but I want to focus on a slightly different aspect of this story: responsible disclosure. Essentially, in responsible disclosure, when a researcher discovers a flaw in proprietary software, they immediately report it to the company responsible and setup a reasonable timeframe for fixing the problem before publicly disclosing the flaw.
Miller first contacted Apple about this problem on October 14th. I’m not sure that three weeks is really enough time to resolve a problem like this. I know he didn’t give all the details, and I know Apple has a reputation for not fixing security bugs until they become public (or perhaps well after they have been public for months…). Still, Miller would have a lot more sympathy with me if he reported the problem to Apple privately and gave them time to resolve the error. Another thing that would have made me a little more sympathetic is if he and Apple had agreed to a timeframe on resolving this problem prior to disclosing the flaw, though I’m not sure Apple would ever agree to something like that. Publicly acknowledging flaws of this nature isn’t really in their DNA.
Despite the flaw in Apple’s code signing, they have been able to respond by removing the exploited app from their app store and canceling Miller’s developer license. (Note: There’s some hypocrisy on Apple’s part here since canceling a developer license is a bit different from their treatment of other iOS security researchers.) Is this good enough for security? Everything in security is a tradeoff, so where does this response fall? It annoys me that there’s a bug in Apple’s code signing, but maybe the setup of the iOS App Store is enough of a response.
The original article points out that a similar issue in Android has resulted in a spate of malware for that platform. I’m not sure a similar thing will happen with iOS. Sure, Apple won’t be able to detect these apps in their review process, but they can always just remove them from the store after they’ve been found in the wild. I would probably prefer to see the code signing exception resolved, but I’m not sure what the tradeoffs really are. It’s hard to make security decisions that way.
Lastly, I should mention that this story is rather one-sided as of now. I haven’t seen anything from Apple about all of this yet. If you’ve seen something from Apple, please leave a comment.
Well-known Mac developer Wil Shipley wrote a fantastic post about software security models on Mac OS X. Essentially, his argument is that proactive solutions to software security cannot be successful on their own; they must be supplemented with a reactive approach. On the surface, this seems counter-productive: wouldn’t you rather find security problems before they compromise anything than react to them after it’s happened? In an ideal world, this would obviously be the best result, but we don’t live in an ideal world. Here’s Wil:
Entitlements are a binary solution – if there’s a hole anywhere in it that malware authors find, then there’s really not much Apple can do until they issue a full operating system patch. We call this kind of solution “brittle” – it requires everything to have been written perfectly, for every contingency, or it fails completely.
Solving security problems proactively is extremely challenging. If there’s a single hole, then all your effort is for nothing. A quick, appropriate reactive response is often the best tradeoff for security. Here’s Wil again:
Code auditing and sandboxing are non-biomimicry – nature doesn’t try to audit every line of code, she tries to fail gracefully. Certificates alone offer a graceful failover – if a developer signs up with Apple and provides false info and manages to trick people into downloading her malware, well, we can just throw a switch and she’s done.
Security shouldn’t be all-proactive, but neither should it be all-reactive. Some proactive measures are worth the tradeoff. The fact that Apple performs a baseline examination of applications sold through their Mac App Store does eliminate obvious security problems, but such an approach is never going to catch every single security problem. For that, the best solution will be reactive, and an application white list enforced with certificates is a reasonable approach.
A couple of weeks ago, Christopher Soghoian tweeted about a short video that’s really a great summary of one of the fundamental privacy problems of cloud computing:
Corporate privacy concerns are more nuanced than government privacy concerns. You can argue that people can just switch to a competitor, as Schmidt does, but how practical is that? Some companies do quite a bit to lock you in. You can argue about creepy advertising, but there’s a real tradeoff there. Some people like seeing relevant ads in certain contexts.
Government privacy concerns are pretty straightforward. They have the guns, so to speak. Even massive corporations like Google cannot prevent the government from accessing your information if the law allows it. Given the state of data privacy laws in the U.S., this is a pretty serious problem for almost every application that uses cloud computing.
Flash is almost always the #1 target for hackers. It’s nearly ubiquitous and easy to break into. The only thing that might give Flash a run for it’s money is the Java runtime environment. Still, Flash is awful.
Because there are so many stories about how bad Flash is from a security standpoint, I haven’t really spent much time linking to them. However, Steve Bellovin, a computer security pioneer and a Professor of Computer Science at Columbia, wrote a fantastic post about the security problems caused by Flash:
From a technical perspective, it’s simply wrong for a design to outsource a critical access control decision to a third party. My computer should decide what sites can turn on my camera and microphone, not one of Adobe’s servers.
Definitely read the whole thing. Bellovin ends his post with this:
No wonder the NSA’s Mac OS X Security Configuration guide says to disable the camera and microphone functions, by physically removing the devices if necessary.
I’m not sure what role the operating system should play here, but it’s fascinating to think about. How should things like the camera and microphone be controlled? Webcams are clearly an important area for privacy.
Lastly, Bellovin’s post is based on research done by Feross Aboukhadijeh at Stanford, which is worth reading if only because it is a pretty compelling case of responsible disclosure.
The EFF spoke with Amazon about their Silk browser, and they appear to be rather satisfied:
We are generally satisfied with the privacy design of Silk, and happy that the end user has control over whether to use cloud acceleration. But this new technology highlights the need for better online privacy protections. As companies continue to innovate in ways that make novel uses of–and expose much more personal data to–the internet cloud, it’s critical that the legal protections for that data keep up with changes technology.
Read their whole article. It breaks down the primary privacy concerns and how Amazon Silk actually handles those situations. If you don’t regularly follow the EFF, they aren’t super easy to please when it comes to protecting users’ privacy, so this is a reasonably strong endorsement.
I haven’t linked to many air travel stories recently in part because there are simply so many of them that picking one to link to over the others is a challenge in and of itself. Recently, I came across an article by LZ Granderson at CNN that sort of summarizes the situation well:
Given the physical requirements and inherent importance of an exit row seat, I would feel more comfortable if I knew the person sitting there could at least do a pushup and not just be collecting a reward for being a repeat customer.
These are the kind of systematic disconnects that just crack me up.
Flight attendants tell us to turn off all electronic devices under the guise they could interfere with the plane’s navigation system, meaning that if the terrorists really wanted to cause some damage, all they had to do was read their Kindle during takeoff.
Granderson sort of implies that we should at least attempt to enjoy the absurdity as the amusement that it is. I don’t agree. Waste and inconvenience on this scale isn’t amusing. Security is a tradeoff, and I don’t think we’re making the right decisions. The risk of being the victim of a terrorist on an airplane is ridiculously low.
There are reasons we’re not making rational decisions about airport security, and most of them are probably best explained by the fact that we’re all human. Humans just don’t make rational decisions about some types of risk. Dan Ariely has basically made his entire career about irrational decisions people make. Bruce Schneier’s next book is going to focus on how people make decisions involving trust.
Still, we don’t really understand why people do are so poor at making these decisions. Worse, we don’t know how to improve this sort of decision making. The absurdity of airport security isn’t amusing; the root causes of this problem are probably one of the most important research topics for the next few decades.
This week Amazon introduced their latest creation: the Kindle Fire. One of the features of the Kindle Fire is a new kind of web browser called Silk. Here’s a video explaining how Silk works:
Silk effectively splits a traditional web browser into a front end that’s running on the local machine and a back end that’s running in the cloud. Chris Espinoza describes it thusly:
The “split browser” notion is that Amazon will use its EC2 back end to pre-cache user web browsing, using its fat back-end pipes to grab all the web content at once so the lightweight Fire-based browser has to only download one simple stream from Amazon’s servers. But what this means is that Amazon will capture and control every Web transaction performed by Fire users. Every page they see, every link they follow, every click they make, every ad they see is going to be intermediated by one of the largest server farms on the planet. People who cringe at the data-mining implications of the Facebook Timeline ought to be just floored by the magnitude of Amazon’s opportunity here. Amazon now has what every storefront lusts for: the knowledge of what other stores your customers are shopping in and what prices they’re being offered there. What’s more, Amazon is getting this not by expensive, proactive scraping the Web, like Google has to do; they’re getting it passively by offering a simple caching service, and letting Fire users do the hard work of crawling the Web. In essence the Fire user base is Amazon’s Mechanical Turk, scraping the Web for free and providing Amazon with the most valuable cache of user behavior in existence.
From the technical descriptions of Silk that I’ve seen, this is pretty accurate. Espinoza later updated his post to say that he doesn’t believe this is a privacy concern:
(9/28 8:45 PST Removed “privacy and.” The piece is about data mining and aggregation, there’s no argument about privacy concerns at all, but people are reading that into it.)
I disagree. Only someone who doesn’t understand the current state of privacy law in the United States would make such a statement. Essentially, by splitting the browser such that all traffic flows through Amazon, they are operating as an ISP. ISPs have numerous privacy concerns. For example, what if the government asked Amazon to provide records of every user who visited a particular website? Currently, this request would fall under something called Third Party Doctrine. Tim Lee describes it as…
the legal principle that, in effect, you lose your Fourth Amendment rights when you relinquish information to a third party. The doctrine has become increasingly important with the rise of modern technology because we now entrust a host of private data — including our email, cell phone calling data, credit card transactions, and more — to private companies, and the third party doctrine would seem to suggest that Fourth Amendment protections would not extend to such information.
The government doesn’t need a warrant to obtain records disclosed to a third party. If it sounds incredible to you that the government wouldn’t need a warrant to obtain something as sensitive as everything you’ve done online with your new Kindle Fire, understand that the government can access your banking records without a warrant because your bank is a “third party” to the data. ISPs are third parties to Internet traffic, and Amazon would be a third party for all Internet traffic on your Kindle Fire. (For more information, please read Jim Harper’s description of how this situation came to be and what we could do about it.)
Om Malik, prompted by Espinoza’s post, got this response from an Amazon spokesperson:
Is Amazon able to peer into its customer usage behavior and use that to offer services based on that data. For instance if you see thousands of your customers going to buy SeeVees shoes from say a store like James Perse at a certain price, can you guys use that data to specifically tailor the Amazon store and offer up deals on those very same pair of shoes?” – the answer is no, as you can see in our terms and conditions, URLs are used to troubleshoot and diagnose Amazon Silk technical issues. Moreover, you can also choose to operate Amazon Silk in basic or “off-cloud” mode. Off-cloud mode allows web pages generally to go directly to your computer rather than pass through our servers. As a reminder, usage data is collected anonymously and stored in aggregate, and no personal identifiable information is stored. It’s also possible to completely turn off the split-browsing mode and use Amazon Silk like a conventional Web browser.
Notice that Amazon says they can’t “peer into customer usage behavior and use that to offer services based on that data.” If this reminds you of Dropbox’s original privacy claim that “All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password,” then you’re not alone. Christopher Soghoian showed that Dropbox could access your files. There are no technical limitations preventing Amazon from using customer usage behavior for whatever they want, just as there were no technical limitations preventing Dropbox from accessing your files. Amazon’s Silk browser will know what websites you visit and what you do on those websites. Amazon will have access to this data. What proof will users have that Amazon isn’t doing whatever they want with that data? Amazon’s terms and conditions basically amount to trust, but “trust me” isn’t enough. This data is too important: emails, financial records, medical records, relationships with friends, and everything else people do on the Internet.
Even if all your browsing data was anonymized prior to being sent to Amazon, anonymous data collection can still violate privacy principles. Bruce Schneier wrote a great article for Wired about anonymized data sets that were publicly released back in 2007. He made this point, which I think is particularly relevant for Amazon’s new Silk browser:
Like everything else in security, anonymity systems shouldn’t be fielded before being subjected to adversarial attacks. We all know that it’s folly to implement a cryptographic system before it’s rigorously attacked; why should we expect anonymity systems to be any different? And, like everything else in security, anonymity is a trade-off. There are benefits, and there are corresponding risks.
Security advocates don’t accept encryption algorithms that aren’t publicly available and haven’t gone through rigorous testing. Privacy advocates shouldn’t accept anonymization algorithms that aren’t publicly available and haven’t gone through rigorous testing. Arvind Narayanan and Vitaly Shmatikov demonstrated this well with the Netflix datasets.
Amazon also said that users could optionally cause Silk to operate as a conventional browser that wouldn’t use Amazon’s cloud to speed up the experience, but this option isn’t enabled by default. Defaults matter. Human psychology demonstrates this in numerous venues. Defaults are also particularly important for technology. The FTC has begun recommending a privacy by design approach, originally described by Ontarioʼs Information and Privacy Commissioner Anne Cavoukia, for technology companies like Amazon. Think tanks concur with this assessment. For example, the Center for Democracy and Technology said the following (emphasis mine):
The FTC should release a set of recommendations outlining the role that Privacy by Design can play in implementing a new set of comprehensive FIPs. These recommendations should emphasize the role of privacy impact assessments, privacy threshold analyses, the integration of PETs into product development, end-to-end lifecycle protection for data, and privacy as the default or as a clear, easy-to-understand alternative.
If Silk is set to the split-browser, cloud-based mode by default, then Amazon isn’t actively practicing privacy by design. No other browser operates like Silk. [Edit: This isn't true. As Charlie pointed out in the comments, Opera Mobile and Opera Mini use a split-browser architecture.] This is new and different, and it has important implications for privacy. Therefore, the privacy by design approach would be to operate as a conventional browser by default and provide users with an option to enable the split-browser, cloud-based mode if they wanted. However, it doesn’t appear as if that’s Amazon’s intention based on their comments to Om Malik.
Amazon has created a new technology with their Silk browser, and they should be applauded for building something new and different. Their Silk browser may speed up the web dramatically for Kindle Fire users, but users should know that there are tradeoffs involved to achieve that speed. In this case, the tradeoff is privacy. If the speed increase is substantial enough, then there are probably many people who would make that tradeoff when using their Kindle Fire. They could do their banking, emailing, or other sensitive surfing at a computer using their preferred security and privacy settings on a desktop browser. However, Amazon isn’t practicing privacy by design, and their terms and conditions are almost deceptive. Amazon should clearly state the technical safeguards put in place to ensure that user data is only used for trouble shooting, and the Silk browser should operate conventionally by default.
If you’re going to steal large amounts of personally identifiable information, then you’re almost always better off doing so digitally rather than attempting to steal paper records. People notice when boxes and boxes of records go missing. In fact, the entire plot of The Firm hinges on a rather intricate attempt to make paper copies of records that would comparatively trivial to steal in a digital world.
Because of the problems of paper records, it’s really rare that you see huge paper-based violations of HIPAA. But apparently, it’s not impossible:
When Athens native Bobby Roberts placed a bid of more than $1,000 for the contents of a delinquent storage unit in Florence, he said he thought he was buying medical equipment and maybe old office files.
But on Sept. 10, when he opened the 20 or so boxes in the unit at Climate Guard Self Storage on Florence Boulevard, he discovered the boxes were filled with personal medical records from Digital Diagnostic Imaging Inc. Some were from as recently as 2009, while others dated to 2002.
Included on those records were not just medical details but patients’ Social Security numbers, addresses, phone numbers, insurance information and driver’s licenses.
Obviously, Roberts didn’t steal the records, but this is still a violation of HIPAA and the fault of the company that abandoned the records. Covered entities can’t just abandon paper-based records in a storage facility. It looks like Roberts is attempting to do the right thing with the records, but imagine what would have happened if someone else had won that auction.
Except where noted, this work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.
RSS feed. This site uses the Basic Maths theme for WordPress, designed by Khoi Vinh & Allan Cole.