Bugs in my oatmeal

I made a bowl of oatmeal this morning, threw some fresh black berries on it, and was about to pour milk on top, which I noticed some movement out of the corner of my eye in the clear plastic container we keep the oatmeal in... at first, I thought it was an ant, and wasn't too creeped out. Then I noticed more. I remember getting these things in our flour when I was a kid, though our flour wasn't in an airtight container. All the same, I couldn't eat the oatmeal I had just made (though I did salvage the black berries).

I'm going to pretend that the bugs (and larvae) weren't in there yesterday when I did eat that oatmeal.

Guess we get to clean out our pantry tonight! Ah, so nice to be back from vacation.... ICK!

This post is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Applied Cryptography, Refereed Papers

Differential Privacy Under Fire
Andreas Haeberlen, Benjamin C. Pierce, and Arjun Narayan, University of Pennsylvania.

There is a lot of data out there that is very important that we try to protect. For example, Netflix knows what movies you watch. Users rate movies in Netflix so that Netflix can make recommendations, but they don't necessarily want to share that information with the rest of the world. Simply replacing people's real names with pseudonyms is not enough, because if people know enough about you, then they will still be able to identify you from the available data and learn even more about you.

Even with protections, people can take advantage of timing attacks where they know the data must be in there, just based on how long the system took to reply to the query.

So, how can we avoid leaking information via query completion time? Their suggestion is to make timing predictable - so regardless of how long the query takes, always return at a constant time. That may mean padding on a delay, or aborting part of the query and returning an error.

By aborting the query, that could actually change the result, but the researchers say that's okay, because the default values will be set to what was expected if the lookout had completed (in this case 1, for true).

Their proposed solution, Fuzz, will pad this time in there, which sounds like it will solve the timing attack, but may make your transactions unacceptably slow, in my opinion.

The audio and video of this presentation are now online.

Outsourcing the Decryption of ABE Ciphertexts
Matthew Green and Susan Hohenberger, Johns Hopkins University; Brent Waters, University of Texas at Austin. Presented by Matt Green.

The researchers have been working on protecting medical records. By using cryptographic control on the records, you can encrypt the record for all valid participants, but that is not very flexible - what if you add, or remove, relevant people?

Attribute-based encryption (ABE) is a little more general. For example, you can encrypt data that can be read by "Cardiologist at Johns Hopkins", so if your cardiologist changes, your new doctor can still access your medical record.

The main problem is that the more complex the policy, the larger the ciphertext grows as well as the decryption time. For example, doing a decrypt on a smartphone could take up to 30 seconds - too long for practical use, particularly if you were a doctor that had to do these decrypts all day long.

The naive approach is to leverage the cloud to assist with the decryption, but you really need to trust your cloud....just too many vectors for attack.

Their approach is to have *two* keys - a transform key (TK) and a secure key (SK). The transform key, which can be in the cloud, can't fully decrypt the ciphertext by itself. The cloud would then partially decrypt the data, and the SK on the phone would complete it.

The researchers found that by doing this transform, which allows external assist, the decrypt time on their iPhone went from 28 seconds to under 2 seconds.

This same research can be applied to smartcards, which are very slow little chips.

The audio and video of this presentation are now online.

Faster Secure Two-Party Computation Using Garbled Circuits
Yan Huang and David Evans, University of Virginia; Jonathan Katz, University of Maryland; Lior Malka, Intel. Presented by Yan Huang.

The researches are trying to implement a system for secure 2-party computation using garbled circuits that is much more scalable and significantly faster than prior work.

This is based on prior work by Andrew Yao from the 1980s. While the garbled circuits theory has been around for a long time, prior implementations have been too slow to be used in practice. The researchers used a Yao chaining garbled circuit, and added a method of parallel processing to speed up the processing time.

Their framework doesn't require people to have expert knowledge about cryptography, but users will need to know basic ideas of boolean circuits. You can learn more and try out their Android app at their website, mightbeevil.com.

The audio and video of this presentation are now online.

This article is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Pico: No More Passwords!

Frank Stajano, from the University of Cambridge, talked about the growing password problem Many years ago, when we all only had one or two passwords to remember, memorizing one or two simple 8 character passwords was very simple to do.

Nowadays, we like have 20-30 (or more?) accounts, all with different password policies, and we just can't memorize them all - and the things we're coming up with that we believe have high entropy, are actually very easily cracked - as illustrated by this recent xkcd.

The little shortcuts we take, like reusing our "good" passwords, means that once it is compromised on one site (through no fault of the user), the attacker has access to many more sites. This was demonstrated recently with the Sony password leaks.

Because we forget passwords, all websites have a method for recovering your password - which can be attacked.

Stajano says that passwords are both unusable and insecure, so why on earth are we still using them?

Perhaps we can start over? Let's get rid of passwords! That's where Pico comes in. The goals of Pico are:

• no more passwords, passphrases or PINs
• scalable to thousands of vendors
• no less secure than passwords (trivial)
• usability benefits
• security benefits

He wants to make sure we stay away from trying to make the user remember things, so that eliminates things like remembering pictures, shapes, etc.

Other requirements for Pico are it must be scalable, secure, loss-resistant, theft-resistant, works-for-all, works from anywhere, no search, no typing, continuous.

Pico would have a camera, display, pairing button and main button, as well as radio to communicate. The device could look like a smart phone, a keyfob, watch, etc, but it is a dedicated device. It shouldn't be on multipurpose device, like an actual smart phone, as it would then be opened up to too many forms of attack.

The camera would use a visual code in order to know what it is trying to authenticate. The radio device would be used to communicate to the computer over an encrypted channel. The main button is used to authenticate, and the pairing button would be used for initialization of an authentication pairing. Obviously, this type of system would not just be an extension of existing systems, but would require hardware extensions.

Pico would initialize by scanning the application's visual code, get the full key via radio and check it against the visual code and stores it. Pico would respond, then, with an ephemeral public key, then challenges the application to prove ownership of the application's secret key. Once all of those challenges are passed, then Pico will come up with it's on keypair for that application and share a long term public key with the application. The application will store that and then would know your Pico the next time you try to connect to that application.

While you're connected to the application, your Pico would be continually talking to the application, via the radio interface.

Of course, simply having the Pico cannot be enough - otherwise someone could take your Pico and impersonate you. This is where the concept of "picosiblings" comes into play. Picosiblings would be things like a watch, belt, ring, cellphone, etc (things you often have with you), and the device would only work with those things nearby. [VAF: Personally, I'd hate to think I wouldn't be able to get money out of the ATM simply because I'd forgotten to wear my Java ring that day].

If you lose your Pico, you'd need to use some of your picosiblings to regenerate it - so don't lose all of your picosiblings as well! It seems that you want to have enough picosiblings, but not too many. I'm not sure how you determine that correct level :)

Pico access can't be tortured out of you, as it can't be unlocked by anything that you know (there's no PIN or password).

"Optimization is the process of taking something that works and replacing it with something that almost works, but costs less." - Roger Needham

With that in mind, Stajano notes that if he actually wants people to adopt this, he would likely need to think of a smart phone client.

There were a lot of interesting ideas in this talk, but the thought of carrying around yet another device is not appealing, and the burden of replacement and function (with all the picosiblings) makes this seem untenable to me - but, if it gets people thinking, then it's definitely a step in the right direction!

The audio and video of this presentation are now online.

This article is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Dealing with Malware and Bots, Refereed Papers

Detecting Malware Domains at the Upper DNS Hierarchy
Manos Antonakakis, Damballa Inc. and Georgia Institute of Technology; Roberto Perdisci, University of Georgia; Wenke Lee, Georgia Institute of Technology; Nikolaos Vasiloglou II, Damballa Inc.; David Dagon, Georgia Institute of Technology. Presented by Manos ANtonakakis.

The motivation is that IP-based blocking techniques cannot keep up with the number of IP addresses that the C&C domains use, as well as there is a time gap between the day the malware is released and the day the security community analyzes it. There is a new tool, Kopis, that can analyze large volumes of DNS messages at AuthNN or TLD [top level domain] servers that will detect malware-related domain names.

Kopis asks the question: who is looking up what and where is it pointing?

The research focused on "interesting domain names" - those that have the most lookup requester diversity and resolvers that are from networks that historically from networks that have been compromised in the past.

Their researchers also looked at the rise of IMDDOS.The first big infection happened in China, and it took between 15-20 days before the US and Europe were infected.

Kopis can be used to detect phishing campaigns by identifying malware-related domains, before a related hash for the attack is identified. You can protect your network before it's infected.

The audio and video of this presentation are now online.

BOTMAGNIFIER: Locating Spambots on the Internet
Gianluca Stringhini, University of California, Santa Barbara; Thorsten Holz, Ruhr-University Bochum; Brett Stone-Gross, Christopher Kruegel, and Giovanni Vigna, University of California, Santa Barbara. Presented by Gianluca Stringhini.

Spam is getting sneakier and sneakier, coming up with subjects and senders that seem relevant to you, which gets it through filters and gets you to open the mail. It's hard to track spambots, as IP addresses of infected machines change frequently and new members can be recruited quickly.

They've been able to find other members of a botnet by assuming that all members will behave in a similar fashion (ie frequency and targets). Additionally, they used a spam trap to populate seed pools (a set of IP addresses that participated in a specific spam campaign) and logs at a Spamhause mirror to find known spammers.

In order to get this right and avoid false positives, they need to have at least 1,000 IP addresses in their seed pool. They came up with a great equation for calculating the threshold for what is really spam, and attempted to label which spam was coming from which botnets.

When they ran their software between September 28, 2010 and February 5, 2011, they tracked 2,031,110 bot IP addresses! The hope is that this software can help to improve existing blacklists.

The audio and video of this presentation are now online.

JACKSTRAWS: Picking Command and Control Connections from Bot Traffic
Gregoire Jacob, University of California, Santa Barbara; Ralf Hund, Ruhr-University Bochum; Christopher Kruegel, University of California, Santa Barbara; Thorsten Holz, Ruhr-University Bochum. Presented by Gregoire Jacob.

Current detection techniques fall into a two categories: host-based techniques, network-based techniques. In order to automatically detect these, you need to be able to examine clean command and control (C&C) logs, but this can be hard as these are often encrypted.

Jackstraws uses a combination of network traces and host-based activity and applies machine learning to identify and generalize C&C related host activity. They achieve the latter by mining significant activities and identify similar activity types.

All of this data is input into jackstraws so it can generate a template for matching other botnets. With lots of interesting graphs, they can now identify C&C traffic from noise.

The audio and video of this presentation are now online.

This article syndicated from Thoughts on security, beer, theater and biking!

USENIX: The (Decentralized) SSL Observatory

Peter Eckersley, Senior Staff Technologist for the Electronic Frontier Foundation, and Jesse Burns, Founding Partner, iSEC Partners, started with the well known crypto stipulation, which is your encryption is only as good as your trust anchor. Knowing that, they wanted to see how secure the X.509 certificates in the wild are, so they started scanning port 443 on IPv4 servers the world over, so they could collect certificates.

They have created an Observatory Browser Extension that collects certificate chain, destination domain, approximate time stamp, optional ASN and server IP that users can install into Firefox that can be used to help the researchers gather more information, and also help you to identify if you've got a bogus certificate in your browser.

Certificate Authorities have a hard job (verifying server identities) with strange incentives (they get paid for each certificate they issue). In 2009 there were three major vulnerabilities due to CA mistakes and in 2010, EFF discovered some evidence that governments were compelling CAs to put in back doors for them. On top of all that, there are a lot of certificate authorities out there. All of these things were daunting to the researchers as they started their project.

The technology this is all based on, X.509, was designed in the 1980s, before TLS/SSL or even HTTP! In their research, they discovered 10,320 kinds of X.509 certificates in the wild, of those, only about 1300 were *valid* (according to SSL).

They found 16.2 million IPs were listening on port 443, and 11 million responded to their SSL handshake.

Typical browsers trust about 1500 CAs. Can that really be a good thing?

These CAs are located in about 52 different countries. They found many certificates that are valid but don't actually identify anyone in particular: localhost, exchange, Mail and private IP addresses [RFC 1918]. What's the point of having a CA verify your identity, if you aren't really providing an actual identity?

They tried to use their browsers to check certificate validity, but had a hard time using it, because Firefox and IE cache intermediate CAs. This means that some certificates are considered valid only sometime (depending on where you've been before with you browser). Clearly, that shouldn't be - a certificate should either be valid, or not.

Even when problems are found and the CA authorities are aware, revocation of problematic certificates is difficult or impossible to do, as many browsers and other software doesn't look at revocation data. They found nearly 2 million revocations, 4 in the future and 2 from the 1970s (before this technology existed).

They found a few subordinate CAs that claim to be from the country "ww" (which doesn't exist), with organization "global" and a bunch of other bogus information - that were irrevocable, and the CPS pointed to dead websites.

So, what can we do? Consensus measurement, more vigilant auditing, DNSSEC + DANE, or certificate pinning via HTTPS headers.

Consensus measurement is where you look for sites to all agree that a certificate is valid, but false warnings can happen when sites swap certificates for testing purposes or for other unknown reasons. Users are already "trained" to ignore warnings if they get too many false positives, so this approach would be problematic.

Certificate pinning relies on whoever used to be domain.com should stay domain.com, which works great if it is implemented correctly. The right way to do this, is to create a private CA just for this domain, and use it in parallel to PKIX. Using this correctly can protect you against compromise and malice, though users would still be vulnerable at first connection.

This article is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Deport on Arrival: Adventures in Technology, Politics, and Power

J. Alex Halderman, Assistant Professor, Computer Science and Engineering at the University of Michigan, started the talk out with a look back at his family history. Apparently his great-grandfather was an illegitimate of a noble and artist, and his grandmother was a spy. As a grad student, back in 2003, he was working on DRM technologies (at the time made to protect CDs - remember those?).

These early copy protections could be easily over-ridden with felt tip markers or by pressing the shift key while inserting a disk. Halderman wrote about this online, and was quickly threatened with lawsuits by the DCMA and the company that had created the DRM technology (their slogan was "Light years beyond encryption").

The next round of DRM technology would install software onto your computer to prevent you from copying CDs - in the form of a rootkit that munged with your registry. Not only was that software doing things that that weren't disclosed, but they also introduced privilege escalation bugs, and if you did uninstall the software, it would leave a remotely executable vulnerability on your desktop.

"Most people, I think, don't even know what a rootkit is, so why should they care about it?" - Thomas Hess, Sony.

Halderman, by publishing these issues, caused Sony to have to recall millions of CDs over the holiday season and brought government oversite into the industry. To the best of his knowledge, attempts at putting DRM software onto CDs has been dropped by the industry. [VAF: though I have seen these recently on CDs I've purchased, at least labeled that it had copy protection.]

Since then, Halderman has been focusing on voting machines, all the way back to the old machines with the big pull levers. In that time, most of the requirements around "robustness" had to do with machines working in hot or cold weather and not losing data if they were dropped.

After the 2000 election debacle, may electronic voting machines were rushed to market without adequate testing and without a third party security review. The code was put up online accidentally by Diebold, and people found many mistakes quite quickly. Diebold claimed the software was out of date and threatened to sue many of the people who had found issues.

In 2008, Halderman and two other researchers finally got their hands on an actual Diebold Accuvote machine, which he acquired from a man in Times Square wearing a trench coat in an alley.... really.

Realizing how litigious Diebold was, the researchers performed their experiments on the machine in a room (missing from the building blue prints) in the basement of their building.

They were able to discover a method to set the percentage of votes they wanted one candidate to get at the end of the voting period, all the while, the paper tape was printing the correct numbers for those voting.

Another method of attack could be done with just 30 seconds of access to the machine with a memory card that would overwrite the voting machine's memory.

Finally, they were able to come up with a voting machine virus that would self-propagate to every voting machine.

Despite these findings, these machines are still used state wide in at least Maryland.

Diebold argued that the box had security in the form of a lock, but the researchers found you could pick the lock with a lock pick set in 10-15 seconds, a little longer with a paper clip. But, why bother? All boxes had the same key, and that same key was also used on minibars and jukeboxes - readily available for purchase on the Internet.

Debra Bowen, Secretary of State in California, took this research to heart and began a full audit of all of California's voting machines and demand e-voting machine manufacturers to provide source code for analysis. The California review found that it wasn't just Diebold that had issues, but all manufacturers of electronic voting machines.

Halderman and other researchers were able to obtain voting machines for next to nothing at various government surplus sales. In one case, they thought, why bother doing this again? We know the box will be insecure. So, instead, the got the voting machine to boot Linux, start X and run a PacMan emulator.... :-)

As states can't seem to find enough bugs in physical electronic voting machines, places like Washington, D.C. wanted to try Internet voting last year. Luckily for Halderman and his grad students, D.C. put the system online a few weeks in advance of voting to allow people to attempt to attack the system.

The students discovered the router passwords were "cisco123" and that there was a publicly accessible webcam in the server rooms. By watching the server rooms for a few days, they knew the schedule of the admin (shown in the talk picking his nose) and when security went home. So, they could launch their attack after 5PM.

They were able to put in false ballots *and* get the system to send them copies of other people's votes. The ballots were encrypted on the server, but the temporary copy of the ballots were not...

Halderman and his researchers did not let D.C. folks know that they were in active attack mode, but wanted to see how long it would take them to notice. They modified the "Thank You for Voting" page to play Michigan's fight song after every vote. It took two days for them to discover this, only because another tester complained to the authorities that he didn't like the new music they'd put on the page - it was annoying.

That still may not have been enough to stop them from deploying. It was also discovered that one of their internal testers wanted to make sure the system wouldn't crash if someone uploaded a very large PDF file, so he uploaded the biggest file he could find... which happened to be the real voter credentials for the election. So, the e-voting was called off... for last year. Wonder what 2011 will hold?

Halderman broke from election talk to tell us about his recent adventures in airports, including filming TSA agents (who don't like to be filmed patting people down, because they feel their privacy is being violated) and wandering around parts of airports that were meant to be secured, but weren't (doors unlocked and security guards were asleep).

Halderman and another researcher went to India to study their electronic voting machines, which previously had not been evaluated by independent researchers. They were able to get their hands on some actual voting systems, and did find that the software was hardcoded into the hardware during manufacturing. So, they attacked the LED display that shows you how many votes each candidate got by making a lookalike board that had chips hidden under the LEDs and a blue tooth transmitter, so you could remotely stack the votes.

The person in India, Hari, who had helped them get access to the voting machine was taken into custody by police a short time later. Fortunately, all ended well for Hari, but it must have been a terrible time while he was in custody. This, of course, led to Halderman being denied future access to India, which he discovered the next time he traveled there.

This was a very entertaining talk, done mostly with pictures, yet it was still very easy to follow. A delight! Once this talk is posted online, definitely check it out!

The audio and video of this presentation are now online.

This article is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Privacy in the Age of Augmented Reality

Presented by Alessandro Acquisti, Associate Professor of Information Technology and Public Policy at Heinz College, Carnegie Mellon University.

Acquisti asks what are the trade-offs associated with protecting and sharing personal information? How, rationally, do we calculate the risk and benefits?

You can look at it from a economics point of view. Acquisti starts with an example from a paper called Guns, Privacy and Crime, analyzing where the state of Tennessee released the names and zip codes of all people that had handgun carry permits. The NRA was outraged, as well as privacy experts, saying this information would make these people at more risk for crime - newspapers believed it would be the opposite. Acquisti and his colleagues studied this and found a direct relation between crime in those areas - that is, crime went *up* in areas with low gun ownership. Obviously, the criminals knew the risk was lower to themselves in those neighborhoods. I'm sure that's not what the state of Tennessee was going for.

The conundrum here, of course, is that different people value their privacy at different levels. He asks us to consider: "Willingness to accept (WTA) money to give away information" vs. "Willingness to pay (WTP) money to protect information." In theory, they should be the same, but in practice, they believed people have a higher WTP.

Acquisti and his colleagues did an experiment at a local shopping mall where they rewarded survey participants gift cards as a reward. One group received a $10 gift card that would not be traced, and the other group was given $12 card that would have the transactions tracked and linked to your name, and they were given the option to swap.

So, while they're both actually being given the same choice, it was psychologically framed differently when presented. People who were originally given the $12 card very rarely wanted to give up the $12 to get their privacy back, while those that started with the $10 card wanted to keep it. If you have less privacy, you value privacy less. McNeally's famous quote, "You have zero privacy anyway. Get over it," came up.

Another area they were curious about was is the Internet really the end of forgetting? That is, memories fade, but Facebook doesn't. I've said this over & over again to teenagers, "The Internet is forever." What the researchers wanted to see was that if people would discount the information if it was old. Their hypothesis was that bad information would be discounted more slowly than good information. For example, if you last received an award 10 years ago, people may say, "Yeah, but what have they done lately," compared to being caught drunk driving, for which you may not ever be forgiven.

Their researchers did three experiments: the dictator game (with real money), the company experiment (judging a real company, but no real money involved), and the wallet experiment (where subjects read about someone doing something either good or bad with a wallet and then judge him).

In the wallet experiment, even though all of this information is fresh on the mind of the subjects, they found that if they said Mr. A did something positive with a found wallet 5 years ago (returning cash found), does not impact people's feelings about Mr. A, whereas if he had done it recently, they would have a more positive view of him. But, if he did something negative (like keeping the cash), it didn't matter if it happened last year or 5 years ago - people did not like this Mr. A.

The lesson learned here is that be careful about letting negative information about yourself from getting on the Internet, as people will not forgive your past indiscretions. The speaker gave specific examples of the Facebook meme where young women post pictures of themselves when they are out of control drunk and passed out or worse. Even as they grow up and mature, they will not be forgiven for those past indiscretions.

And, with computer facial tagging getting better and better, even untagging yourself won't prevent you from being recognized.

The researchers studied public Facebook profile pictures along with their IDs and compared them to publicly known pictures of those people to see if people are using their real picture - they were able to discover that about 85% of them were accurate images. This could be further leveraged to see if people are using their own real picture on dating sites :)

What this means, is that even if you change your name, you still won't be able to escape your face (well, not without significant cost and potentially negative consequences).

The better and faster that facial recognition software gets, the less privacy we will have in public. Someone you just met could look you up by your face and learn all sorts of information about you. Scary!

The audio and video of this presentation are now online.

This article is syndicated from Thoughts on security, beer, theater and biking!