The technology being evaluated is the Helios Online Voting Booth, usable at http://www.heliosvoting.org and outlined in the 2008 Usenix Secuirty paper available at the same site. The election system does not create novel cryptographic tools or algorithms, rather it provides a protocol for using existing cryptography to make an election that is universally verifiable and provides ballot casting assurance as well as voter secrecy. The general outline of the system is as follows:

• The voter fills out a ballot and then “seals” it by essentially encrypting it with the election’s public key so that only the election administrators can decrypt it.
• The voter then has the option of verifying that the sealed ballot contains her same choices, if chosen requires the voter to “reseal” it with new randomness.
• The voter is then authenticated and, if allowed to participate in the election, their ballot is “cast” to the server and the voter receives a copy of their sealed ballot.
• Upon receipt, the server publicly publishes the voter’s name and sealed ballot so the voter can verify that the sealed ballot is the same as the one cast.
• Upon election conclusion, the server downloads all sealed ballots from the previously mentioned public place and scrambles and re-encrypts them with a mixnet.
• The server then decrypts all ballots and tallies the totals, providing proof of correctness.

The paper contains a few proposed improvements to current weaknesses, but I still felt it reasonable to discuss those weaknesses. More information on the broader implications of this system was presented in a Current Events article published earlier today.

Assets and Security Goals

• The election system needs to provide ballot casting assurance. The voter needs to be able to verify that his/her ballot was received, and received correctly in order for him/her to deem the election valid. The makes sure that the voting system cannot change or destroy a voter’s ballot without the voter being able to find out.
• The election system needs to provide universal verifiability. Anyone must be able to independently and externally verify that all votes that were received were, in fact, counted and counted correctly in order for the election to be known to be valid. This, with the above, makes sure that not even the election administrators can tamper with the election.
• The election system needs to provide voter secrecy. It should be impossible for anyone to link a voter and his/her vote in order for voters to be free to vote for whomever he/she wants without fear of punishment.

Adversaries and Threats

• Anyone (including the election administrators) wishing to fix an election for monetary, religious, or political gain may try to change or destroy ballots or tamper with ballot counting without being discovered.
• Anyone wishing to discover who voted for whom may try to link individual voters and ballots, either during or after voting.

Potential Weaknesses

• It is possible, just after the voter casts his/her ballot, for a corrupt router to intercept the ballot en route to the Helios server and send the user a fake Helios server success code, causing the “voting booth” to immediately display a false success message and clear the ballot from memory. At worst, the voter fails to later check that their ballot was recorded on the server before the end of the election and his/her ballot is never counted. At best, the voter realizes their vote was not counted and has to cast a new ballot.
• As it currently exists, if the election administrator allows Helios to administrate the election (as it seems they suggest doing), it is possible for a corrupt Helios server to create new, fake voters and cast ballots on their behalf without easily being discovered. Since the system relies upon voters validating their votes, it would be difficult to distinguish between actual voters who didn’t validate their vote and server-generated voters.
• As the client-side code utilizes jQuery, LiveConnect, and Java BigInteger libraries, any vulnerabilities or cryptographic insecurities in that code could potentially be exploited to tamper with the election.
• As currently implemented, the election administrator (who has the power to add voters and freeze the election) is authenticated through Google Accounts. Any vulnerability in the login (weak password, easily guessed security questions, etc.) could allow an attacker to end the election prematurely or add additional voters (potentially multiple accounts for the same voter).

Potential Defenses

• The main defense the Helios system uses to prevent the sort of ballot manipulation or rejection described in the first weakness is to provide open-source tools for the user to verify that the ballot they have created (but not yet cast) does indeed contain the desired voting preferences. This seems to be the best-possible solution short of forcing the user to verify their ballot because it should be inherently impossible to validate the values in a ballot after it has been cast (otherwise others could view the values as well).
• The Helios defense against a corrupt Helios administering a server and creating fake voters is to provide means for other election administrators to acquire and store the election’s private key necessary for decrypting the votes.

Risks and the Big Picture

• The risks associated with this sort of system are nothing less that selling democracy to the highest bidder, or at least the one with the most computing power. If this sort of system were eventually used for a governmental election, the key lengths (currently 1024) would need to be significantly larger because the stake is so much higher. All of a sudden the researchers with 10,000 PS3 cells, or the BBC with a botnet of 10,000 computers might be able to crack encryption keys and tamper with ballots or fake election results. Since this system is based upon computational security, it needs to be implemented in such a way that even the best of the FBI cannot affect the results. Otherwise the currently established government could control all subsequent election results.
• Most of the risks can be alleviated through complete voter validation of their ballots in combination with auditing of the election results given the provided proofs of correctness which are part of the system. If many voters do not do this, however, then it is possible for many security flaws to go unnoticed.

Conclusion

The general idea is that here is finally a system which seems to hint that it may be possible to design an electronic voting system that is secure and transparent. The details have obviously not been ironed out, and may not be for some time, but the spirit of the system is enough to provide some hope in this era where Diebold Premier Election Solutions voting booths are still being used in US elections. The Helios system is not the solution, but it is a step in the right direction, if for no other reason than Kerckhoffs would be rolling in his grave if he knew how we trusted Diebold’s secret code to run this democracy. When not even the government in charge of an election can alter its outcome without the public being able to check, elections may finally be able to be trusted.

Sources

http://www.physorg.com/news155473407.html
Adida, B., Helios: Web-based Open-Audit Voting, Usenix Security 2008

Now the BBC group is in a spot of legal trouble as their use of a botnet could potentially implicate them in the violation of the UK’s Computer Misuse Act. While BBC claimed that their use of the botnet was purely academic, and therefore not criminal, they did take control of non-consenting citizens’ home PCs. More importantly, in purchasing the use of a botnet, reportedly at somewhere between $300-$400 per machine, the news network essentially funneled a few million dollars into the hands of cybercriminals. And all so that they could demonstrate what many papers and news articles before them already had.

The journalists, at surface level, did a good job of keeping things academic and avoiding any sort of cybercrime. They spammed their own test e-mail accounts. They DDoS’d a prepared and willing target. They also put warning documentation on the infected machines, at experiment’s conclusion, explaining to their users that they had been infected, and how to best avoid future infections. Ultimately, however, by mere involvement with and commandeering of hijacked personal machines – and especially thanks to funding the true criminal party – they did indeed commit some level of criminal act. To what degree they are held responsible is now a matter for the British courts to decide.

This is just one more occurrence in a string of botnet-related legal issues. A similar issue plagued German malware researchers with the means to potentially dissolve the Storm worm’s botnet(s) (see http://cubist.cs.washington.edu/Security/2009/01/11/storm-worm-cracked-but-defenses-may-not-fly/). It seems that academicians of all types are running into a fundamental problem with this particular security threat: there is no way to legally study it “in the wild.” The moment a researcher connects to a botnet, takes control of it, or otherwise interacts with it, he or she risks legal consequences. Whether or not any charges stick is a different matter, and quite frankly, it will take some time before reasonable precedents clarify the legal “consensus,” but regardless these issues represent a significant impediment to progress in anti-botnet research.

This project rose out of the recognition that relatively recent advancements in cryptography and computer science have paved the way for the possibility of actually implementing election protocols that guarantee ballot casting assurance, universal verifiability, and voter secrecy. One issue that the developers of this system are facing is that the public is not really aware (or if they are, they fail to recognize the implications) of the lack of these properties in our current election system. Especially as absentee balloting is becoming more popular, there is little guarantee that 1) your vote is ever received, 2) that no one changed en route, 3) that it was counted at all, and 4) that is was counted correctly. The Helios system allows the user to verify 1, 2, and 3, and allows anyone to verify 4. The source for the Helios system is available for free under Creative Commons, and an online server is available for general use.

This new development is especially important given the recent Diebold debacle which emphasized the importance of Kerckhoffs’ principle in the development of important security systems. Entrusting something as important as democracy to some proprietary, secret code hacked up by some people under investigation for putting Trojans in ATMs is no way to go. It will be interesting whether or not this new style of election will ever be used in general governmental elections, but it hints that the day when we may actually be able to cast e-votes with confidence is drawing near. If you are interested in more details of the Helios system, a follow-up security review will be posted shortly.

Assets

This application gives access to friends and potential adversaries to learn the valuable personal information. The goal is to maintain this information private – protect from potential attackers, leakage, and inappropriate use.

• Location. Leaking the information regarding someone’s location creates a huge personal security thread. One could see this way where the target is at a given time. A robber could check if the target is far away from where his car is parked to break in, for example.

• Daily routine. By monitoring the person for a while, one can reconstruct his schedule, and know where the person is expected to be at different time, and what he does. From here we can see that attacker could manipulate this data and determine with a high degree of accuracy what you will be doing at different parts of the day and can setup events even as maniacal as a car theft or something even more extreme like a mugging or home robbery.

• Destinations. It could be hard to keep in mind that your personal information is potentially on somebody’s screen at all times. There might be the destinations that one could prefer to keep secret, but it would be revealed without person even realizing it. If one was at some point at the dentist’s office for 30 minutes it can be deduced that you maybe there for a simple cleaning vs. if he spent a good 2-3 hours it may indicate some more major work. Other information that one might not like to share can be learned: shopping at the sex-shop, going out to a gay club, being at somebody’s house late at night, and so on.

Adversaries

The information can be used to confront one on his locations throughout the day. Using this method it would be very easy for a person to identify that their spouse has been cheating on them, or for a parent to know when their child has seemingly lied about where they intend to spend the night.

• Friends/family. Friends, family and whoever else one might decide to give access to can see where he is at all times of the day. People might not realize sometimes, that even though they don’t mind allowing their friends to see their location, this could result in some other people also gaining access to information. For example, one gives access to his friend, but his friend has a roommate who he shares a computer with. Also the friend does not usually log off his account. This way, his roommate can see the information he was not supposed to have access to.If the roommate is also malicious it makes the situation even more unfortunate. Also, if a friend is not as friendly as it seems, he might decide to use the information regarding personal location against the account holder.

• Stalkers. The application is an incredibly useful tool for stalkers, because this way they can learn where to find the person, and what the person does.

• Thieves. The robbery can be planned out basing on the information learned from the Google Latitude. For example, people can make sure that nobody is home to break in.

Weaknesses

There are some many inherent by design flaws in this system. For starters users do not have to necessarily be entrusted with this information to get a hold of it.

• Insiders to the company. People that have access to see other’s profile could use/leak the information even if against company’s policy.

• Internet security. Weak passwords, cookies, etc. Even though one can chose not to give somebody access to use the application to identify the location of the person, this parameters can be changed without person even realizing it. Internet security is not perfect. People are often able to gain access of restricted web pages, and other information that is intended to be protected.

• Invisibility. One person might not even be intending to use the application, and not want to share it with anybody at all. It’s enough for an attacker to know the username and password of the person, to unnoticeably set up the tool, and add himself/others to trusted circle. All the notifications about this set up could be deleted right away, and future notifications turned off. This way the owner of the account might not find out for a long time, that somebody is capable of tracking them down.

• Awareness of potential consequences. Many times people are not even aware that they are giving out such sensitive information or have not thought through the consequences of it. Since they may not realize the impact of this information they might be more susceptible to sharing it with people that should not have these privileges. User awareness is a growing issue not only with features such as latitude but also with many different tools and online services that are used today.

• Possibility of social attacks. There are some inherent by design flaws in this system. For starters users do not have to necessarily be entrusted with this information to get a hold of it. If there is a person you know who has access to the information it most likely wouldn’t take much to get your hands on it.

Defenses

• Automatic log outs if the user has not been actively using the system for a certain time. In addition, automatic log outs if the application notices anything suspicious, such that somebody inquiring about a person too often. Also require a person an extra step to login to Google Latitude, to display the location to friends.

• Increase of personal awareness. Such as application warning every time a new person is added in the trusted circle, and maybe an e-mail about this change. Turning off or disabling the service is foremost most effective way to defend yourself against potential malicious intentions. Limiting your trusted friends to a minimum and communicating to them clearly that they should not give anyone the information about you that you have shared with them.

• Provide statistics. For self check, users could see statistics on how often other people look him up, for example. This way user could have a chance to identify or notice if anything suspicious was going on.

• Advanced setting to dynamically disable the service, or not inform certain people if you enter a specified zone, which is set to private. For example, since you know that you have a sensitive routing in the morning you may opt to have the service be off, and turn on after you’ve returned to your save public locations, so that your friends have a way to easily find you, only when it does not disclose any private/secret information.

Evaluation and Conclusion

The risks although seem so minor really dependent on a case by case basis. It’s one thing for Joe the plumber to have Latitude running on their mobile phone or laptop vs. the Chief of Staff or better yet the President of the United States. In these situations their security is only as good as the security of the service itself. Since nothing is bullet proof it is possible for people to invade this private information and use it for their own private gain. As technology evolves more and more we will always continue to worry about its security and vulnerabilities.
Nonetheless, there will always be risks involved with the system no matter what you do to protect or for any precautions that you take, you most likely will slip up at one point. The service as a whole has good intentions to allow your friends and family to maintain awareness of your locations at all times for everyone’s convenience including your own. As opposed to sending messages or mail to 15 people every 30 minutes informing them of your location, those 15 people need only open a URL and look at a map. The real weakness of this system isn’t so much the system itself but the human element that interacts with the system.

Assets/Security Goals

• The money in the checks
• The personal information and signatures on the checks

Adversaries

• Non residents interested in stealing money or identity
• Residents interested in the same
• Residents interested in forcing neighbors into late fees or the like

Weaknesses

• The checks are left in the box often for days. This means there is a significant amount of time during which the box can be compromised without anyone noticing.
• Common areas are accessible not only by residents, but quite easily by non-residents: guests, or strangers who follow a resident through the main door.
• The key lock is often a very weak lock which is easily picked or broken.
• The box itself is often cheap a flimsy or is fastened together with regular screws. Using a screw driver in the easiest case, or to the extreme a crow bar or brute force.

Potential Defenses/Conclusion
There are several solutions which could alleviate to a large extent these security risks. An overriding weakness of these solutions is that they are relatively expensive compared to the cheap cost of existing drop boxes and the biggest stake holders (the residents paying rent) are not in charge of choosing the solution (the building managers). Nevertheless, I will discuss some possible solutions. There are two basic levels of the solution. Limiting access to the box: general complex security measures like double door entrances, keys on more doors before getting to the drop-box area and the like, as well as only leaving checks out for a shorter period of time (perhaps collecting several times a day during payment periods. Making the drop box more secure: stronger boxes and locks would prevent access to the checks. Moreover, other methods such as direct delivery (in person) to the managers would eliminate most of these vulnerabilities. These solutions either compromise convenience (for example delivering directly to manager means that more coordination is required) or money (for example more expensive boxes or locks).

Summary:

ComputerWorld had an article about Google Voice.  Google Voice is a new service offered by Google to make people’s phones more usable.  Google Voice will automatically transcribe a user’s voicemail into text form, using speech recognition software.  Because the transcription is done with software, there may be some mistakes in the text versions.  The transcriptions will be made available in the user’s inbox.  The service can also e-mail or SMS the messages to you. If I user desires the service can be turned off.

Google Voice builds on the technology of GrandCentral, a company that Google bought a few years ago.  This technology allows a user to have a single number for all of their phones.  When this number is dialed, all of the associated phones also ring.  In this way, a user can be contacted regardless of which phone (home, work, cell, etc…).  Google Voice will initially be offered to current users of GrandCentral.

Assets:

The assets involved are a significant amount of a user’s personal data.

• User’s phone numbers: this is obviously necessary for the technology to work.  Though this information can be found in phonebooks, some people value the privacy of this data.  A person’s phone number can be used for telemarketing, stalking, or (sometimes) even physical tracking using Google Latitude.
• User’s e-mail address: this is needed in order to e-mail transcriptions to a user.  These are valued to avoid spam and other unwanted communications.
• User’s personal information: this is the big one!  Recording a user’s messages may include incredibly sensitive information (perhaps messages from a mistress or creditors).  This information is now converted from sound to text, stored on Google’s servers, sent by e-mail.

Adversaries/Threats:

• Stalker: a person motivated to snoop into the details of your life could learn quite a bit about you from this service.  This personal information could be used to embarrass, blackmail, or incarcerate the user, depending on what was found.
• Government: the government could break into Google Voice, or perhaps subpoena Google into releasing its databases to law enforcement.  This could be used to monitor suspected terrorists or punish petty crimes.

Potential Weaknesses:

• I assume that a user’s transcriptions are password accessible, even if not sent by e-mail.  If this is true, then all the normal password weaknesses apply: the user may have chosen a poor password, it may be a password shared with another site, etc.
• If transcriptions can also be accessed directly from one of the phones included in the GrandCentral list, then this phone must send some signal to Google.  This signal could be recorded, and it is likely that a successful replay attack could then be staged.
• Users are frequently a weak link in the security of any system, and this will hold true for Google Voice as well.  Many users are unlikely to think about the possible security consequences associated with this service.  This may lead them to make especially poor security choices.
• If a user opts for transcriptions to be e-mailed or SMSed to them, there is the additional possibility that these messages can be intercepted.  Google may have very little control of the security of these services, which likely makes this a weak link.

Potential Defenses:

• The transcription database should be encrypted and otherwise properly protected.  It should be secure from physical access, and few employees within Google should have any kind of access to it.
• Google should take steps to properly educate the users of Google Voice of the security concerns.  Specifically, it should mandate “good” passwords and attempt to inform users about the risks inherent in converting private conversations to text, which can easily parsed by computers.  Similarly, it should warn users about the additional risks involved in e-mailing the transcriptions.

Evaluate Risks:

I think that the risks posed above have the potential to cause users significant harm.  However, much of the personal information above can be found by other means already.  The fact that we already have voicemail means that precisely this information is already in databases somewhere, albeit in voice rather than text form.  Moreover, much of this information is likely redundant to other sources of information on a person, which could be found using Google searches, dumpster diving, and general stalking.  For this reason, the biggest risk of Google Voice is that it makes personal information more accessible to adversaries than previously possible, assuming the adversaries can compromise Google’s security measures.

Conclusions:

I am highly suspicious of this service and will not be using it myself.  However, it should be noted that the vast majority of this information is already available in voicemail databases.  I do not think that this technology, if appropriately implemented, poses any new significant threats to the assets listed above.

Reference: ZDNet

It is unknown exactly what exact SQL injection string was used to gain access to the database of user emails and passwords, but SQL injection attacks are not terribly difficult attacks to defend against. Considering the email addresses and passwords were stored in plaintext, and considering the wide range of methods to protect code from SQL injection, it is likely this attack was only possible because the coders of the website were careless and did not think much about security risks when designing the website.

There are several obvious things the programmers could have done to protect themselves from this attack. For one, it is clear that they did not properly validate user input. It’s not clear exactly how vulnerable the search was – whether the input was completely raw or if it just didn’t catch all possible illegal characters – but certainly they should have had extra precautions to sanitize the input strings. They could have also changed the permissions of the database such that users have the least privileges possible. It is unlikely that a user searching a database of properties needs access to the table with passwords and email addresses. Finally, they could have stored encrypted passwords and email addresses. Encryption doesn’t solve all problems, but it is good practice anyway and is part of the system’s defense-in-depth.

This event brings to light several interesting issues. For one, the group who found the bug is a “self-confessed ethical hacker group” called Hackersblog. When they found the bug, they reported it on their blog instead of privately disclosing it to The Telegraph. This is because they feel that everyone (clients included) has the right to know about security vulnerabilities. It does bring up ethical issues, however – no work of code is be perfect, so it’s highly likely that there are going to be security holes somewhere. Does Hackersblog have the right to reveal this information to the public? And is it even a good idea to have a group of “ethical” hackers? (About the group and statement on philosophy)

It is also important to realize how dangerous a leak like this is. Even though getting access to the emails and passwords for newspaper subscriptions does not seem like a very important issue, one must keep in mind that most users have the same password for everything. The article cites that 61% of people use the same password for a variety of websites, so a password leak anywhere can lead to disastrous problems.

Obviously The Telegraph should fix these bugs, but it should also think about how to incorporate more secure practices into all parts of their system. Had they been designing their system with a security mindset all along, it is unlikely such an attack would be possible.

The Air Force Institute of Technology has a new method for passive BitTorrent tracking. The system attempts to read the header of BitTorrent packets, and compare the hash in the packet to a known set of bad hashes. If a bad hash is matched, then the system logs it for future investigation. The system uses programmable FPGAs, and sniffing capacity tops out at 100Mbps.

Recent developments in traffic shaping / packet analysis have been largely spurred by large ISPs’ desire to limit user’s consumption of high-bandwidth services such as BitTorrent. Complaints towards users of BitTorrent include high bandwidth usage, as well as accusations of illegally sharing copyrighted material.

However, packet inspection at any level raises a number of privacy concerns, as systems at the ISP level would definitively be reading the data that flows through their network from an end user’s machine. This can either be malicious or not — it really depends on how ISPs use it. It seems like ISPs are highly motivated to keep traffic down so that they can keep their networks from becoming congested. However, no ISP customer can ever exceed the maximum amount of bandwidth that they are advertised to get. It seems like the ISPs are not being forthcoming about the real amount of bandwidth that they want customers to use.

Bandwidth isn’t the only issue, with litigation being handed out to file sharers. It’s in the ISP’s best interest to stay out of any legal issues they can, which also provides a good motivator for packet shaping BitTorrent traffic. However, given millions of motivated BitTorrent users versus companies with relatively limited resources, they are fighting an uphill battle that will not end up in their favor. This Air Force sniffing technology can’t detect encrypted BitTorrent packets, which compromise 25% of the BT traffic out there. As well, with projects such as OneSwarm, people can set up much more anonymous sharing networks between friends. The only way for corporations to survive file sharing is to adapt, like the Norwegian state broadcasting company did when it started offering its broadcasts as full, unencrypted downloads on its own hosted BitTorrent tracker.

According to the Technology Review article, these programs does its job pretty well; for example, the Apple program can learn as the user tells it which matching are right and which are wrong. Scarily, Google’s program, Picasa, which has pictures stored on Google database, will cluster the pictures according to the faces, let the users tag those clusters with names and allow them to further match it to the corresponding people’s email addresses. It is a little bit unsettling that “before [we] know it, Google is asking [us] to identify all those other faces in [the] photographs” fulfilling its corporate mission “to organize the world’s information and make it universally accessible and useful” while that is not what we want from a photo-sharing website.

The photo recognition system starts to be used after the September 11 attack. Obviously this is done to help screen out terrorists at security checkpoints, such as airports and federal facilities. This can be helpful for the airport security officers to concentrate more on other details of the passengers, rather than on their face. The question now is whether this system has high enough accuracy to identify people by their face, regardless of their other facial features, such as beards or wigs.

One obvious concern with widely available face recognition is privacy. Due to real-name tagging and the fact that email addresses are unique, Google’s Picasa is able to create a global database linking people’s email addresses, names and photos recognized as a particular person together. This is not a new privacy issues; having facial recognition tools adds to the information that is exposed on the web.

One simple way to minimize the exposure or potential violation of your own privacy is to not use these tools. Although, unfortunately, like all new tools which exposes more information about us on the web, there will be hype regarding privacy management. This should be no different.

Source: http://www.technologyreview.com/computing/22234/page1/

Xia Cam and Devy Pranowo