<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>UW Computer Security Research and Course Blog &#187; Policy</title>
	<atom:link href="http://cubist.cs.washington.edu/Security/category/policy/feed/" rel="self" type="application/rss+xml" />
	<link>http://cubist.cs.washington.edu/Security</link>
	<description></description>
	<lastBuildDate>Tue, 17 Mar 2009 01:02:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Current Event : Keyboard hacking (from thin air!)</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/current-event-keyboard-hacking-from-thin-air/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/current-event-keyboard-hacking-from-thin-air/#comments</comments>
		<pubDate>Sat, 14 Mar 2009 06:43:51 +0000</pubDate>
		<dc:creator>kosh</dc:creator>
				<category><![CDATA[Miscellaneous]]></category>
		<category><![CDATA[Policy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1310</guid>
		<description><![CDATA[A move over scanning the keyboard with infra-red cameras for heat signatures, listening to keystrokes and simple shoulder surfing.
Say hello to hacking through thin air or electromagnetic waves, rather. Apparently, all keyboards generate unique electromagnetic waves for every single key pressed and these are really easy to pick up even with some inexpensive antennae. Of [...]]]></description>
			<content:encoded><![CDATA[<p>A move over scanning the keyboard with infra-red cameras for heat signatures, listening to keystrokes and simple shoulder surfing.</p>
<p>Say hello to hacking through thin air or electromagnetic waves, rather. Apparently, all keyboards generate unique electromagnetic waves for every single key pressed and these are really easy to pick up even with some inexpensive antennae. Of course, a lot of this is only possible under ideal conditions where there isn&#8217;t much interference from other devices. Here are some videos that demonstrate the attack -</p>
<p><em><strong>Edit: Looks like embedding is disabled here. Please visit the links below for the videos</strong></em></p>
<p>Sources :</p>
<p><a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;taxonomyName=security&amp;articleId=9129575&amp;taxonomyId=17&amp;intsrc=kc_top" target="_blank">Computer world</a></p>
<p><a href="http://lasecwww.epfl.ch/keyboard/" target="_blank">Ecole Polytechnique Federale de Lausanne</a></p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/current-event-keyboard-hacking-from-thin-air/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Current Events: One more botnet-related legal fray</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/current-events-one-more-botnet-related-legal-fray/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/current-events-one-more-botnet-related-legal-fray/#comments</comments>
		<pubDate>Sat, 14 Mar 2009 04:52:13 +0000</pubDate>
		<dc:creator>oterod</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Policy]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Research]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1265</guid>
		<description><![CDATA[ As part of an “expose’” on cyber crime, BBC’s “Click” team took it upon themselves to hire a botnet. With the stated goal of demonstrating the power of “cyber criminals” in today’s world, the journalists purchased the use of ~22,000 compromised machines. As part of their demonstration, they directed massive amounts of spam to [...]]]></description>
			<content:encoded><![CDATA[<p class="MsoNormal"><!--[if gte mso 9]&gt;  Normal 0     false false false  EN-US X-NONE X-NONE              MicrosoftInternetExplorer4              &lt;![endif]--><!--[if gte mso 9]&gt;                                                                                                                                            &lt;![endif]--> As part of an “expose’” on cyber crime, BBC’s “Click” team took it upon themselves to hire a botnet. With the stated goal of demonstrating the power of “cyber criminals” in today’s world, the journalists purchased the use of ~22,000 compromised machines. As part of their demonstration, they directed massive amounts of spam to two specific test addresses, and finally, used their botnet to bring down a security firm’s backup website via DDoS. The DDoS attack was done with permission from the “victim” company (Prevx).</p>
<p class="MsoNormal"><span> </span>Now the BBC group is in a spot of legal trouble as their use of a botnet <span> </span>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.</p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal">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.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/current-events-one-more-botnet-related-legal-fray/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Security Review – Mobile Banking in the Developing World</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/12/security-review-%e2%80%93-mobile-banking-in-the-developing-world/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/12/security-review-%e2%80%93-mobile-banking-in-the-developing-world/#comments</comments>
		<pubDate>Thu, 12 Mar 2009 09:00:32 +0000</pubDate>
		<dc:creator>cxlt</dc:creator>
				<category><![CDATA[Physical Security]]></category>
		<category><![CDATA[Policy]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Security Reviews]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1078</guid>
		<description><![CDATA[
One of the interesting topics brought up by Microsoft Research India during their Change talk last week was that of mobile banking in the developing world.  Managing and distributing money can be a tricky proposition in the developing world – often, people end up entrusting their money to drivers to transfer around the city [...]]]></description>
			<content:encoded><![CDATA[<p><img style="border: 1px solid #dddddd; margin: 5px; padding: 3px; float: right; width: 150px; height: 200px;" src="http://blogs.sun.com/hinkmond/resource/images-2008/mobile-banking.jpg" alt="mobile banking" /></p>
<p>One of the interesting topics brought up by <a href="http://research.microsoft.com/en-us/labs/india/">Microsoft Research India</a> during their <a href="http://change.cs.washington.edu/">Change</a> talk last week was that of mobile banking in the developing world.  Managing and distributing money can be a tricky proposition in the developing world – often, people end up entrusting their money to drivers to transfer around the city or country.</p>
<p>Mobile banking through cell phones has proven to be an extremely cost-effective way to avoid these kinds of headaches.  Through both downloadable software and text message interfaces, it is possible to efficiently transfer and manage money without the existence of local branches to handle the transaction, with minimal fees and far less obvious physical risk.  However, this method has resulted in its own set of idiosyncrasies that would not likely exist with similar systems elsewhere.</p>
<p>Afraid of doing something wrong, many people in these developing areas are reluctant to actually carry out their own banking.  Thus, a whole class of middlemen have arisen specifically for mobile banking.  People will bring their mobile phones into these middlemen&#8217;s stores and tell the store owners what they want done, and the middlemen will then go do it for them.  This interesting use case leads to quite a few security implications.</p>
<h2>Assets and Security Goals</h2>
<ul>
<li><strong>Customers&#8217; money</strong> is of course important.  The reasons should be fairly obvious – we of course want to protect it from being stolen.</li>
<li><strong>Customers&#8217; financial records</strong> are also important – financial histories are private, with some exceptions, and they should stay that way.  Knowing how much money someone has may put them at risk for a real-life robbery, for instance, or knowing their stock portfolio could cause other problems.</li>
</ul>
<h2>Adversaries and Threats</h2>
<ul>
<li><strong>Malicious third parties</strong> who would like to steal the customers&#8217; money, perhaps by listening to the airwaves, or physically stealing the phone.  A lot can be done with just a few seconds with a phone given a text messaging interface.</li>
<li><strong>The middlemen</strong> have an extraordinary amount of power given what they have been entrusted with by the end-users.  And, since their clients won&#8217;t have it any other way, banks have been forced to actually work with these middlemen, including them in the system.  A store owner could easily pull off an “<em>Office Space</em>” type scheme, stealing miniscule amounts of money from each customer.</li>
</ul>
<h2>Potential Weaknesses</h2>
<ul>
<li><strong>Snooping on peoples&#8217; wireless connections</strong> is difficult since the network provides some level of intrinsic security.  We&#8217;re not experts on this subject, so it&#8217;s difficult for us to assess how feasible this approach is in reality.</li>
<li><strong>Replay attacks</strong> are possible, especially if any actions are carried out via text message, and a malicious user manages to take over the phone physically, or duplicate/forge the SIM card.</li>
<li><strong>Physical access</strong> is an imminent problem given the prevalence of these middlemen in transactions.  Somehow, even with physical access by users other than the clients there needs to be security and accountability.</li>
</ul>
<h2>Potential Defenses</h2>
<ul>
<li><strong>For snooping</strong>, simply use any of the well-established encryption protocols we discussed this quarter.</li>
<li><strong>Replay attacks</strong> can be guarded against by confirming each action with a code that can only be used once.</li>
<li>The <strong>physical access</strong> problem is the most difficult problem to address – and the most interesting.  Since third parties are allowed access to the system by the clients, it is difficult to enforce anything in the system if the third party is malicious.  One way to defend against third party mischief would be to not carry any actions out immediately, but instead to queue them and then confirm them via text message with the client an indeterminate amount of time in the future, on the order of several hours.  This way, hopefully clients will be forced to examine and acknowledge all actions away from the influence of the store owners.  Malicious middlemen could counter this by requesting to keep the phone until the transaction is complete, but hopefully clients would grow suspicious of this request before long.</li>
</ul>
<p>Mobile banking is something that hasn&#8217;t quite caught on here like it has in other places of the world.  Not only is it useful for banking when branches aren&#8217;t nearby, the service has in some places, like Japan, evolved to include payments via cell phone rather than credit card, and other technology-enabled services which have security implications.  Ultimately, a lot of these problems are already being worked on in the context of their low-tech equivalents (eg transmitting credit card information, etc), but as we can see with the rural banking case study, there can be a lot of unexpected usages which result in unexpected potential problems.</p>
<p>These unexpected issues are likely where we will see the most interesting security issues in the future.</p>
<p><span style="color:#bbb">Clint Tseng and Erik Turnquist</span></p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/12/security-review-%e2%80%93-mobile-banking-in-the-developing-world/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Facebook&#8217;s lax security</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/08/facebooks-lax-security/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/08/facebooks-lax-security/#comments</comments>
		<pubDate>Mon, 09 Mar 2009 05:30:37 +0000</pubDate>
		<dc:creator>zhaoz</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Policy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1050</guid>
		<description><![CDATA[Facebook&#8217;s policy on applications have a some people concerened and wondering if application writing should be more restricted.
The latest attacks have involved privacy leaks, and the installation of malware. Over the last week, five seperate security issues have come up. One virus is a variation of &#8220;Koobface&#8221; which claims that the user must download a [...]]]></description>
			<content:encoded><![CDATA[<p>Facebook&#8217;s policy on applications have a some people concerened and wondering if application writing should be more restricted.<br />
The latest attacks have involved privacy leaks, and the installation of malware. Over the last week, five seperate security issues have come up. One virus is a variation of &#8220;Koobface&#8221; which claims that the user must download a plugin to view a video.</p>
<p>Applications on facebook are not vetted, anybody is allowed to write an app and offer it to other people. Viral apps would often hide functionality in innocently looking buttons to spread themselves further or give away private information. Despite Facebook&#8217;s efforts to disable applications, the current policy allows it to pop up elsewhere.</p>
<p>Some people have clamored for the application hosting policy to be reviewed. Facebook believes its too early for these conclusions, and that changing the policy would be too drastic of a move.</p>
<p>(Source: <a href="http://www.nzherald.co.nz/web-2-0/news/article.cfm?c_id=363&amp;objectid=10559681&amp;ref=rss">nzherald</a>)</p>
<p>(Source: <a>cnet</a>)</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/08/facebooks-lax-security/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Current Event: Convicted Botnet Leader Retains Job</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/07/current-event-convicted-botnet-leader-retains-job/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/07/current-event-convicted-botnet-leader-retains-job/#comments</comments>
		<pubDate>Sun, 08 Mar 2009 04:15:28 +0000</pubDate>
		<dc:creator>eapter</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Policy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1047</guid>
		<description><![CDATA[In three sequential articles, ComputerWorld traces the sentencing of convicted botnet leader John Schiefer as well as his continued employment at the start-up Mahalo.  Schiefer is an ex-security consultant and is the first botnet leader to be charged under the wiretap statutes.  He entered his guilty plea almost a year ago, but sentencing has been [...]]]></description>
			<content:encoded><![CDATA[<p>In <a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;taxonomyName=cybercrime_and_hacking&amp;articleId=9129054">three</a> <a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9129098">sequential</a> <a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9129178">articles</a>, <a href="http://www.computerworld.com/">ComputerWorld</a> traces the sentencing of convicted botnet leader John Schiefer as well as his continued employment at the start-up <a href="http://www.mahalo.com/">Mahalo</a>.  Schiefer is an ex-security consultant and is the first botnet leader to be charged under the wiretap statutes.  He entered his guilty plea almost a year ago, but sentencing has been delayed until now.  He will be paying $2,500 in fines, paying nearly $20,000 in restitution, and spending 4 years in prison  Perhaps what is more interesting is that Mahalo&#8217;s CEO Jason Calacanis has both allowed Scheifer to continue working during this time and has expressed a desire to offer him a job upon his release from prison.  Calacanis has defended this decision on the basis that he trusts Schiefer and considers him a changed man from the person who committed the earlier crimes.</p>
<p><span id="more-1047"></span>Clearly, Schiefer&#8217;s sentencing is a consequence of pleading guilty to the charges against him.  When he originally obtained his job at Mahalo, his employers were not aware of his criminal activities.  They learned of these crimes months after his hiring.  However, Calacanis decided not to fire him at that time and stands by that decision: &#8220;I consider myself a fairly decent judge of character, and after spending months with John, I’m convinced he was an angry stupid kid when he launched his botnet attack.&#8221;  Regardless of the accuracy of Calacanis&#8217;s  assessment, Schiefer is able to keep his job because he gained the trust of his coworkers and employer.  In their eyes, he became a person (John Schiefer) instead of a nebulous concept (botnet leader).  This speaks to the importance of trust within our society.</p>
<p>Though Calacanis claims that Mahalo&#8217;s hiring process is quite rigorous, it seems that a simple background check would have been sufficient to bring Schiefer&#8217;s past to light (assuming he had already been identified by authorities at the time of hiring).  If this wasn&#8217;t done, then Mahalo failed at ensuring the integrity of their hires.  If this was done and there was no information, than Mahalo can hardly be held accountable for the original oversight.  Another interesting aspect of this case is that Calacanis claims this has affected his perspective on hiring felons.  Where previously he said most felons would not have made it to the interview process, his experience with Schiefer has given him some faith in the rehabilitation process and prompted him to rethink his position.</p>
<p>This event brings out important issues about security, trust, and rehabilitation.  No one doubts that Schiefer committed the crimes to which he pled guilty.  What is an issue is that he is continuing to work in the industry that made his original crimes possible.  Even if he continues to be closely supervised, this will give Schiefer ample opportunity to perform more attacks in the future.  However, much of the justification of our country&#8217;s penal system is the idea that, after serving one&#8217;s time, a person can become rehabilitated.  This allows a person to re-integrate with society and make something of himself.  Certainly Schiefer is being given that opportunity, but there is significant security risk in the process.</p>
<p>Because of the two conflicting ideas of security and rehabilitation, I expect that different people will have different opinions on this matter.  Furthermore, I suspect that despite disagreeing on the proper course of action, many people would agree that they are &#8220;good&#8221; judges of character.  I think that if they met Schiefer they, like Calacanis would have a firm opinion of the proper course of action, whichever course of action they happen to support.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/07/current-event-convicted-botnet-leader-retains-job/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Security Review : Add-ons</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/13/security-review-add-ons/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/13/security-review-add-ons/#comments</comments>
		<pubDate>Sat, 14 Feb 2009 05:14:42 +0000</pubDate>
		<dc:creator>kosh</dc:creator>
				<category><![CDATA[Policy]]></category>
		<category><![CDATA[Security Reviews]]></category>
		<category><![CDATA[addons]]></category>
		<category><![CDATA[browser]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=936</guid>
		<description><![CDATA[An add-on is a simple plugin that you use, say for firefox, to let you do your work more easily. This also lets you customize the browser in ways that do not affect the productivity of other people. Add-ons are becoming a major part of the browser functionality but sans the scrutiny that goes into [...]]]></description>
			<content:encoded><![CDATA[<p>An add-on is a simple plugin that you use, say for firefox, to let you do your work more easily. This also lets you customize the browser in ways that do not affect the productivity of other people. Add-ons are becoming a major part of the browser functionality but sans the scrutiny that goes into developing a browser.</p>
<p>Assets and Security Goal:</p>
<p>* Assets: Your browser, everything that you use it for and your cookies. Uh, not the ones you eat. and privacy.<br />
* Security Goal: Protect your privacy at all cost and your cookies and your intimate browsing secrets!</p>
<p>Adversaries and Threats:</p>
<p>* Unauthorized publishers: This is the dreaded group of publishers that are able to make an add-on for your browser and pass it off as being legitimate and harmless. This is much easier than you think since most add-ons are unverified or rather community verified and it might take a while to find an exploit.</p>
<p>Weaknesses:</p>
<p>* Counterfeit add-ons are the biggest risk &#8211; a majority of the add-ons are through unverified authors.<br />
* Deceived by community rating. Since the rating for the plugins is done by the community, an obscure/malicious add-on can be easily made to look like a legitimate one through a community of attackers/ an attacker with a community of profiles.<br />
* Unauthorized plugins from third party websites.</p>
<p>Defenses:</p>
<p>* Other legitimate users &#8211; These are probably the best and most formidable defense when it comes to validating add-ons. However, this also a delayed defense since &#8216;enough&#8217; users will have had to use the add-on for someone to finally detect a malicious exploit.<br />
* Firewall &#8211; Your firewall is also your second line of defense when preventing backdoor access through the malicious add-on<br />
* Antivirus software &#8211; An up-to-date virus definition file should help the software detect a malicious plugin. However, this also assumes that the attacker used a known exploit/trojan/virus to inject into the add-on.<br />
* Security updates from the browser, OS &#8211; These can help patch the exploits that are currently in place.</p>
<p>Risks:<br />
The risk of being duped means to lose a significant amount of personal information that is stored in the browser. With the shift of browser towards acting like an OS with features to save passwords,sessions, etc, there is an unbelievable amount of personal information that can be stolen through a malicious add-on. The add-on can also redirect to malicious websites that involve elaborate phishing scams leading to the loss of information and money. Such attacks give the hacker a complete control of your online portfolio which can be held for ransom and also misused, causing personal damage.</p>
<p>Conclusion:<br />
Overall, although there are inherent risks to open source projects like a community browser, a large part of the attacks are easily mitigated due to the sheer number of users that pass through such an add-on. There also seems to be significant,active and unofficial community that monitors the plugins for malicious intent. One way to decrease the probability of such an attack would involve letting a significant time pass from the release of the plugin to the installation for it to be tested by active community members. Filtering the installation of add-ons also becomes an important but often impossible task in a corporate environment where the risks are especially high. Add-ons(unsigned) are definitely a double edged sword that need to be dealt with care.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/13/security-review-add-ons/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Police Searches of Personal Electronics</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/06/police-searches-of-personal-electronics/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/06/police-searches-of-personal-electronics/#comments</comments>
		<pubDate>Fri, 06 Feb 2009 22:46:46 +0000</pubDate>
		<dc:creator>asekine</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Policy]]></category>
		<category><![CDATA[Privacy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=724</guid>
		<description><![CDATA[Source:
Cnet
In June 2008 Florida Highway Patrol officer John Wilcox pulled over Ariel Quintana for speeding, who was then discovered to be driving with a suspended license. The officer also suspected Quintana of being in possession of marijuana, but a search of the car revealed nothing. While in custody, Quintana&#8217;s phone rang and officers removed the [...]]]></description>
			<content:encoded><![CDATA[<p>Source:<br />
<a href="http://news.cnet.com/8301-13578_3-10158244-38.html">Cnet</a></p>
<p>In June 2008 Florida Highway Patrol officer John Wilcox pulled over Ariel Quintana for speeding, who was then discovered to be driving with a suspended license. The officer also suspected Quintana of being in possession of marijuana, but a search of the car revealed nothing. While in custody, Quintana&#8217;s phone rang and officers removed the phone without permission and started searching the contents of the device.</p>
<p>While going through the photo album, pictures were discovered of what appeared to be marijuana plants in a grow house. This resulted in a raid of Quintana&#8217;s address, which led to the seizure of over $850,000 worth of marijuana plants.</p>
<p>This is not the first case where a personal electronic device was searched without warrant that resulted in further evidence being used against a suspect in custody for an unrelated crime. Given the increasing presence and integration of personal electronics in every aspect of our lives, PDAs and cellphones can provide the most intimate details about their owners. As such, there is debate about whether the owners&#8217; privacy should be protected given the nature of the information they contain, or if they should be considered containers and/or accessories for crimes which police should be able to search for further evidence for use in court, without the need of a warrant. As the article indicates, courts are split on this topic and there is still much debate about how these cases should be handled.</p>
<p>In order to prevent future incidences such as this from occuring again in the future, politicians and courts have to agree upon which circumstances searching digital devices is allowed, if at all.Given the nature of the types of information and data stored on personal devices, laws dealing with them must adapt to take the sensitivity of this information into account. The number of cases such as this will only increase with time, and policies need to be introduced to deal with this increasingly relevant issue. Individuals need to be aware of their rights, especially given the information at stake</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/06/police-searches-of-personal-electronics/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Arrested in Washington?  Give us your DNA!</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/05/arrested-in-washington-give-us-your-dna/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/05/arrested-in-washington-give-us-your-dna/#comments</comments>
		<pubDate>Fri, 06 Feb 2009 01:04:16 +0000</pubDate>
		<dc:creator>eapter</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Miscellaneous]]></category>
		<category><![CDATA[Policy]]></category>
		<category><![CDATA[DNA]]></category>
		<category><![CDATA[law]]></category>
		<category><![CDATA[Privacy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=643</guid>
		<description><![CDATA[As I found on Slashdot, a controversial piece of legislation is being considered that would allow for the collection of DNA from arrested persons.  The DNA may be collected prior to the arrested person being charged with a crime, and the arrest can be for crimes as minor as shoplifting.  The DNA would [...]]]></description>
			<content:encoded><![CDATA[<p>As I found on <a href="http://news.slashdot.org/article.pl?sid=09/02/05/1545241">Slashdot</a>, a <a href="http://www.thenewstribune.com/news/government/story/615841.html">controversial piece of legislation</a> is being considered that <a href="http://seattletimes.nwsource.com/html/politics/2008704869_dna04m0.html">would allow for the collection of DNA from arrested persons</a>.  The DNA may be collected prior to the arrested person being charged with a crime, and the arrest can be for crimes as minor as shoplifting.  The DNA would be sent to State Patrol and FBI databases, where it would be compared against DNA collected in unsolved crimes.  If the person who was arrested is not charged, is not convicted, or has her conviction overthrown, her DNA would be destroyed.</p>
<p><span id="more-643"></span></p>
<p>
Proponents argue that collecting DNA upon arrest would increase public safety, and that DNA collection is not intrinsically more invasive than fingerprinting and photographing, both of which are done routinely upon arrest.  Opponents counter that DNA collection is more invasive than the other information and that collection of DNA upon arrest inverts the assumption of innocent-until-proven-guilty.  Moreover, many people who are arrested are never charged, let alone convicted.</p>
<p>This legislation is being considered in part because it has been adopted in 12 other states.  This provides a sort of precedent that may make the law more appealing to some.  Similarly, the public is very aware of the existence of DNA evidence (thank you CSI).  Combined with the fact that crimes are committed, this prompts some people to advocate for increased public safety, and they view this measure as an appropriate means of achieving this goal.</p>
<p>This legislation is a prime example of two social assets that seem to frequently conflict: 1) individual rights (especially privacy) and 2) safety.  It is debatable which one is actually better for security.  Preferring an individuals rights does not give the police additional information that they would otherwise lack.  This protects the assets of those who are arrested, since they are presumed innocent until proven guilty.  However, if this person is going to commit (or has already committed) other crimes the police may lack the information needed to intervene.  Preferring safety gives the police additional information, which may allow them to intervene in a timely manner but does not protect the arrested person&#8217;s individual rights.</p>
<p>I expect that the response to this issue in the general public will be generally divided, but that most will support the legislation.  I suspect that the majority of the people in this class will oppose it.  I know that I oppose it.  I think that it is a costly, ineffective, and unconstitutional reaction caused by public fear.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/05/arrested-in-washington-give-us-your-dna/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Current Event: WarCloning Passport RFID Tags</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/02/current-event-warcloning-passport-rfid-tags/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/02/current-event-warcloning-passport-rfid-tags/#comments</comments>
		<pubDate>Tue, 03 Feb 2009 06:03:05 +0000</pubDate>
		<dc:creator>rctucker</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Policy]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[rfid]]></category>
		<category><![CDATA[WarCloning]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=613</guid>
		<description><![CDATA[According to Slashdot, researcher Chris Paget was able to capture many identification numbers from the new passports containing RFID tags while driving around San Francisco. Using $250 of equipment (a RFID reader and an antenna) hooked up to his laptop, Paget was able to read the identification numbers of the passport RFID tags from up [...]]]></description>
			<content:encoded><![CDATA[<p>According to Slashdot, researcher Chris Paget was able to capture many identification numbers from the new passports containing RFID tags while driving around San Francisco. Using $250 of equipment (a RFID reader and an antenna) hooked up to his laptop, Paget was able to read the identification numbers of the passport RFID tags from up to 20 feet away. According Paget, it could be possible to read the tags from hundreds of feet away since they are actual radio signals. It is then &#8220;trivial to program&#8221; a blank tag with the retrieved identification numbers. It is these numbers that are used in verifying the RFID tag.<span id="more-613"></span></p>
<p>The concern that arises are the issues of privacy and identity theft. The passport RFID tags do not contain any personal or identifying information themselves, but when they are combined with the information gleaned from other RFID tags that an individual may be carrying, it then becomes possible to track an identity. Paget gives an example of how this can be done. By combining RFID readers at a door way or an entrance, it would be possible to read the tags of driver&#8217;s licenses and credit cards (both of which *do* contain identifying information) and match them with the passport identification number. Since it was demonstrated that the passport tag could be read at a distance of many feet instead of inches, a person could be tracked using their passport RFID and their identity would be linked using the data from their driver&#8217;s license and credit cards.</p>
<p>Paget has posted a video on YouTube that demonstrates how he accomplished this feat. In it, he mentions two security features built into the passport RFID. They are a lock code and a kill code. The lock code is suppose to prevent the identification number in an RFID tag from being altered. The kill code is intended to disable the tag completely. Paget describes how, when read, these codes are transmitted over plaintext allowing anyone to intercept them. Although Paget admits that only the identification number is used in verification, if the lock and kill code are ever used for verification they are easy to capture.</p>
<p>This should come as a serious concern to those receiving passports and the new driver&#8217;s license, as this has been a known concern for some time even though few have been bold enough to demonstrate how easy it is to break this system. Paget does not believe that any personal identification documents should ever contain RFID tags and says his ultimate goal of his research is to &#8220;see the entire Western Hemisphere Travel Initiative just be scrapped.&#8221; Though these RFID tags make it more convenient for travelers and security personnel alike, the convenience comes at a cost.</p>
<p>It will be necessary for the government to address these security problems for the general public to trust the RFID tags. This will likely mean that the data must be encrypted instead of being broadcast over plaintext. It may also mean reducing the range at which the passport RFID tags can be read. However, even if these problems are addressed, this does not fix the problems created by RFID tags in other devices such as driver&#8217;s licenses and credit cards. To truly address this problem, it may be necessary to remove RFID tags from cards that do not require them. At a minimum, it will require removing identity information from the cards and encrypting data that must be read.</p>
<p>Links:<br />
http://it.slashdot.org/article.pl?sid=09/02/02/2224255<br />
http://www.theregister.co.uk/2009/02/02/low_cost_rfid_cloner/<br />
http://www.youtube.com/watch?v=9isKnDiJNPk<br />
http://darkreading.com/security/privacy/showArticle.jhtml?articleID=213000321<br />
http://www.engadget.com/2009/02/02/video-hacker-war-drives-san-francisco-cloning-rfid-passports/</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/02/current-event-warcloning-passport-rfid-tags/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Security Review: Pandemic Prevention</title>
		<link>http://cubist.cs.washington.edu/Security/2009/01/30/security-review-stopping-pandemics-one-cough-at-a-time/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/01/30/security-review-stopping-pandemics-one-cough-at-a-time/#comments</comments>
		<pubDate>Fri, 30 Jan 2009 23:08:45 +0000</pubDate>
		<dc:creator>hmu2</dc:creator>
				<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Miscellaneous]]></category>
		<category><![CDATA[Policy]]></category>
		<category><![CDATA[Security Reviews]]></category>
		<category><![CDATA[security review]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=558</guid>
		<description><![CDATA[According to a New Scientist Article, a company called Biorics wants to control the spread of pandemic disease by dispersing “cough-detecting” microphones throughout airport lounges. The proposed technology would detect coughing passengers and distinguish a common-cold-like cough from one that could be a symptom of a serious and spreadable disease. In 1998, a group of [...]]]></description>
			<content:encoded><![CDATA[<p>According to a <a href="http://www.newscientist.com/article/dn16499-innovation-sick-traveller-detectors.html">New Scientist Article</a>, a company called Biorics wants to control the spread of pandemic disease by dispersing “cough-detecting” microphones throughout airport lounges. The proposed technology would detect coughing passengers and distinguish a common-cold-like cough from one that could be a symptom of a serious and spreadable disease. In 1998, a group of scientists from the Nippon Medical School in Tokyo, Japan showed that they could discriminate between productive and non-productive coughs; where a productive cough is usually accompanied by the expulsion of phlegm (i.e. a sick person’s cough). Biorics used this research to develop a system that theoretically could detect a sick traveler in an airport and stop the spread of a possibly devastating disease.</p>
<p><span id="more-558"></span>Assets:</p>
<ul>
<li> The obvious security goal of this technology is to reduce the spread of potentially pandemic disease by detecting it early. By detecting disease in airport lounges, the international spread of serious illnesses can be mitigated.</li>
<li> A secondary use of this technology and a possible asset is to detect illnesses in livestock to prevent the spread of animal-borne disease. By detecting animal “coughs” that indicate serious illness, food safety issues and health hazards caused by sick livestock could be avoided.</li>
</ul>
<p>Threats:</p>
<ul>
<li> Third parties (e.g. CIA, NSA, etc.) could get access to conversation/location data.</li>
<li> Adversaries could infect a specific individual and track him and record his conversations as he travels. Or a group of adversaries could all infect themselves with a non-terminal disease that would give them a distinguishable cough in order to potentially quarantine an entire airport. Stranding hundreds of travelers would not only be costly, but would result in a prime target for large scale terrorist attacks.</li>
<li> Airport workers who have access to recorded data/control of the microphones would be able to intentionally misinterpret the data to detain a specific individual. A person with access to this data could also record and manipulate conversation and location data.</li>
</ul>
<p>Weaknesses:</p>
<ul>
<li> One potential weakness is filtering microphone data from crowded, noisy areas. Yelling, loud noises, or fake coughing could cause a false positive.</li>
<li> Another weakness is attempting to contain an infected individual once a disease is identified. Numerous other travelers would have to be quarantined as well in order to actually prevent an outbreak. This seems costly and incredibly inconvenient. Also, this situation could result in many healthy people becoming infected by being quarantined with the infected individual.</li>
<li> This technology would require constant monitoring of incoming data and numerous employees to track down and quarantine infected individuals. This could be costly.</li>
<li> One of the biggest weaknesses from a traveler’s point of view is that this technology inflicts yet another way to make traveling slow and inconvenient.</li>
</ul>
<p>Defenses:</p>
<ul>
<li> A simple cough screening (just like taking off your shoes, checking your bags, etc.) could be administered while people go through security. A doctor or health worker would have to be present in order to verify the disease in travelers who test positive.</li>
<li> By only allowing doctors/health workers (rather than a security guard) to access the data, privacy could be better maintained.</li>
<li>In order to speed up the quarantine process for possibly infected passenger, a quick test should be developed to confirm/verify illness on site. This would allow healthy but misidentified passengers to be on their way sooner.</li>
</ul>
<p>Risks:</p>
<ul>
<li> People’s privacy could be violated in several ways: medical data could be leaked, conversations could be monitored/recorded, and people’s location could be tracked.</li>
<li> Even if the above risks were addressed, this system would only be effective if every major airport adopted it, which seems unlikely given the lack of consistency in airport procedures worldwide.</li>
<li> This technology is not very likely to evolve because it is too invasive and too likely to be abused.</li>
</ul>
<p>Although this technology is well-intentioned and could be a very powerful tool for preventing the spread of diseases, the potential for abuse and invasion of personal privacy is too great. If this technology was used more overtly, as described in our possible defenses section, it could be more accepted. Implementing this technology for livestock has greater potential, as animals have less concern about their privacy . Preventing the spread of diseases in livestock could also greatly impact the spread of animal-to-human transmittable disease.</p>
<p>Authored By: Heather Underwood &amp; Guy Bordelon</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/01/30/security-review-stopping-pandemics-one-cough-at-a-time/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
