Slashdot Mirror

Engineers at the University of Michigan have created the world's smallest computer -- again. From a report: The University held the record for the smallest computer after it created its 2x2x4mm Michigan Micro Mote in 2014. The Micro Mote (or M3) is fully functional and able to retain its programming and data even when it loses power. But after IBM debuted an even tinier "computer" in February, a 1mm x 1mm chip with "several hundred thousand" transistors.

Engineers at the University of Michigan were not about to be one-upped, and quickly created an even smaller computer, so small it could fit on the tip of a grain of rice. However, the engineers quibbled over whether IBM's machine and the new Michigan design could really be called computers, since the data gets wiped as soon as it's turned off. You can find more details on the university's website.

Dan Goodin reports via Ars Technica: Attackers can cause potentially harmful hard drive and operating system crashes by playing sounds over low-cost speakers embedded in computers or sold in stores, a team of researchers demonstrated last week. The attacks use sonic and ultrasonic sounds to disrupt magnetic HDDs as they read or write data. The researchers showed how the technique could stop some video-surveillance systems from recording live streams. Just 12 seconds of specially designed acoustic interference was all it took to cause video loss in a 720p system made by Ezviz. Sounds that lasted for 105 seconds or more caused the stock Western Digital 3.5 HDD in the device to stop recording altogether until it was rebooted. The device uses flash storage to house its firmware, but by default it uses a magnetic HDD to store the large quantities of video it records. The attack used a speaker hanging from a ceiling that rested about four inches above the surveillance system's HDD. The researchers didn't remove the casing or otherwise tamper with the surveillance system. The technique was also able to disrupt HDDs in desktop and laptop computers running both Windows and Linux. In some cases, it even required a reboot before the PCs worked properly. The paper titled "Blue Note: How Intentional Acoustic Interference Damages Availability and Integrity in Hard Disk Drives and Operating Systems" can be found here (PDF).

An anonymous reader quotes a report from IEEE Spectrum: Last August, reports emerged that U.S. and Canadian diplomats in Cuba had suffered a host of mysterious ailments. Speculation soon arose that a high-frequency sonic weapon was to blame. Acoustics experts, however, were quick to point out the unlikeliness of such an attack. Among other things, ultrasonic frequencies -- from 20 to 200 kilohertz -- don't propagate well in air and don't cause the ear pain, headache, dizziness, and other symptoms reported in Cuba. Also, some victims recalled hearing high-pitched sounds, whereas ultrasound is inaudible to humans. The mystery deepened in October, when the Associated Press (AP) released a 6-second audio clip, reportedly a recording of what U.S. embassy staff heard. The chirping tones, centered around 7 kHz, were indeed audible, but they didn't suggest any kind of weapon. Looking at a spectral plot of the clip on YouTube, Kevin Fu, a computer scientist at the University of Michigan, noted some unusual ripples. He thought he might know what they meant.

Fu's lab specializes in analyzing the cybersecurity of devices connected to the Internet of Things, such as sensors, pacemakers, RFIDs, and autonomous vehicles. To Fu, the ripples in the spectral readout suggested some kind of interference. He discussed the AP clip with his frequent collaborator, Wenyuan Xu, a professor at Zhejiang University, in Hangzhou, China, and her Ph.D. student Chen Yan. Yan and Xu started with a fast Fourier transform of the AP audio, which revealed the signal's exact frequencies and amplitudes. Then, through a series of simulations, Yan showed that an effect known as intermodulation distortion could have produced the AP sound. Intermodulation distortion occurs when two signals having different frequencies combine to produce synthetic signals at the difference, sum, or multiples of the original frequencies. Having reverse engineered the AP audio, Fu, Xu, and Yan then considered what combination of things might have caused the sound at the U.S. embassy in Cuba. "If ultrasound is to blame, then a likely cause was two ultrasonic signals that accidentally interfered with each other, creating an audible side effect," Fu says. "Maybe there was also an ultrasonic jammer in the room and an ultrasonic transmitter," he suggests. "Each device might have been placed there by a different party, completely unaware of the other."

An anonymous reader writes: "Mobile applications that open ports on Android smartphones are opening those devices to remote hacking, claims a team of researchers from the University of Michigan," reports Bleeping Computer. Researchers say they've identified 410 popular mobile apps that open ports on people's smartphones. They claim that an attacker could connect to these ports, which in turn grant access to various phone features, such as photos, contacts, the camera, and more. This access could be leveraged to steal photos, contacts, or execute commands on the target's phone. Researchers recorded various demos to prove their attacks. Of these 410 apps, there were many that had between 10 and 50 million downloads on the official Google Play Store and even an app that came pre-installed on an OEMs smartphones. "Research on the mobile open port problem started after researchers read a Trend Micro report from 2015 about a vulnerability in the Baidu SDK, which opened a port on user devices, providing an attacker with a way to access the phone of a user who installed an app that used the Baidu SDK," reports Bleeping Computer. "That particular vulnerability affected over 100 million smartphones, but Baidu moved quickly to release an update. The paper detailing the team's work is entitled Open Doors for Bob and Mallory: Open Port Usage in Android Apps and Security Implications, and was presented Wednesday, April 26, at the 2nd IEEE European Symposium on Security and Privacy that took place this week in Paris, France."

An anonymous reader quotes a report from The Stack: Researchers at the University of Michigan have created an app that makes any smartphone pressure-sensitive without additional hardware. The app, called ForcePhone, uses ultrasonic tones in the existing microphone and speaker hardware that respond to pressure for additional functionality for touchscreens. The app emits a high-frequency ultrasound tone from the device's existing microphone, which is inaudible to humans but can be picked up by the phone. That tone is calibrated to change depending on the pressure that the user gives on the screen or on the body of the phone. This gives users an additional way to interact with their device through the app alone. The additional functionality provided by ForcePhone can be used in a number of ways. Squeezing the body of the phone could take a user back a page, for example; or increased pressure on the touchscreen could act as a 'right-click' function, showing additional information on the app in use. Kan Shin, Professor at the University of Michigan, said, "You don't need a special screen or built-in sensors to do this. Now this functionality can be realized on any phone." He added, "We've augmented the user interface without requiring any special built-in sensors. ForcePhone increases the vocabulary between the phone and the user."

Researchers have discovered flaws in Samsung's Smart Home automation system, which if exploited, allows them to carry a range of remote attacks. These attacks include digitally picking connected door locks from anywhere in the world. The flaws have been documented by researchers from the University of Michigan ahead of the 2016 IEEE Symposium on Security and Privacy. "All of the above attacks expose a household to significant harm -- break-ins, theft, misinformation, and vandalism," the researchers wrote in a paper. "The attack vectors are not specific to a particular device and are broadly applicable." Dan Goodin, reports for Ars Technica: Other attacks included a malicious app that was able to obtain the PIN code to a smart lock and send it in a text message to attackers, disable a preprogrammed vacation mode setting, and issue a fake fire alarm. The one posing the biggest threat was the remote lock-picking attack, which the researchers referred to as a "backdoor pin code injection attack." It exploited vulnerabilities in an existing app in the SmartThings app store that gives an attacker sustained and largely surreptitious access to users' homes. The attack worked by obtaining the OAuth token that the app and SmartThings platform relied on to authenticate legitimate users. The only interaction it required was for targeted users to click on an attacker-supplied HTTPS link that looked much like this one that led to the authentic SmartThings login page. The user would then enter the username and password. A flaw in the app allowed the link to redirect the credentials away from the SmartThings page to an attacker-controlled address. From then on, the attackers had the same remote access over the lock that users had.

An anonymous reader writes: According to scientists, a single U.S. shale oil field is responsible for much of the past decade's increase in global atmospheric levels of ethane, a gas that can damage air quality and impact climate. The Bakken Formation, an oil and gas field in North Dakota and Montana is spewing nearly 2% of the globe's ethane. That translates to about 250,000 tons each year. "Two percent might not sound like a lot, but the emissions we observed in this single region are 10 to 100 times larger than reported in inventories. They directly impact air quality across North America. And they're sufficient to explain much of the global shift in ethane concentrations," said Eric Kort, U-M assistant professor of climate and space sciences and engineering.The Washington Post has more details (paywalled; alternatively you can read this Gizmodo report)

the_newsbeagle writes: We don't often get insider accounts of hacks against major institutions like hospitals because they immediately go into damage control mode. But at a SXSW talk, a couple of experts told tales out of school. The experts, [John Halamka, CIO of the Boston hospital Beth Israel Deaconness, and Kevin Fu, a University of Michigan engineering professor, recounted incidents in which hackers downloaded patient X-rays to China, took down entire networks, fooled Harvard doctors, and more.

A team from the UK's National Oceanography Centre (NOC), University of Michigan and NASA's Jet Propulsion Laboratory have discovered a new way to accurately measure the sea level. The technique is called GNSS-R, and involves bouncing low-powered signals from GPS satellites off of the ocean's surface and measuring the reflected signal with a GNSS-R receiver. The team used a research satellite launched last year as a GNSS-R receiver, but it will be able to tap a new constellation of receivers that NASA is launching this year as part of CYGNSS. That mission will make accurate measurements of surface winds using GPS satellites, but NOC scientists will be able to use them to measure ocean levels, too, yielding a thirty-fold increase in such data.

An anonymous reader writes: According to game historian Jon Peterson, Gary Gygax's Chainmail fantasy wargame (which became the basis for Dave Arneson's Blackmoor and later Dungeons & Dragons) borrowed heavily from an earlier set of rules published by Leonard Patt, a long-forgotten member of the New England Wargamers Association. Among the appropriations were rules for heroes and wizards including the iconic fireball spell, which ended up in everything from Magic: the Gathering to World of Warcraft, as well as monster rules for dragons, orcs, ents, and other Tolkien creations. Gygax had something of a reputation for borrowing things without giving proper credit, and this latest revelation shows how the open and collaborative environment of early gaming was quickly exploited for commercial purposes.

HughPickens.com writes: According to a recent study of 27 schools, about one-quarter of female undergraduates said they had experienced nonconsensual sex or touching since entering college, but most of the students said they did not report it to school officials or support services. Now Natasha Singer reports at the NYT that in an effort to give students additional options — and to provide schools with more concrete data — a nonprofit software start-up in San Francisco called Sexual Health Innovations has developed an online reporting system for campus sexual violence. One of the most interesting features of Callisto is a matching system — in which a student can ask the site to store information about an assault in escrow and forward it to the school only if someone else reports another attack identifying the same assailant. The point is not just to discover possible repeat offenders. In college communities, where many survivors of sexual assault know their assailants, the idea of the information escrow is to reduce students' fears that the first person to make an accusation could face undue repercussions.

"It's this last option that makes Callisto unique," writes Olga Khazan. "Most rapes are committed by repeat offenders, yet most victims know their attackers. Some victims are reluctant to report assaults because they aren't sure whether a crime occurred, or they write it off as a one-time incident. Knowing about other victims might be the final straw that puts an end to their hesitation—or their benefit of the doubt. Callisto's creators claim that if they could stop perpetrators after their second victim, 60 percent of campus rapes could be prevented." This kind of system is based partly on a Michigan Law Review article about "information escrows," or systems that allow for the transmitting of sensitive information in ways that reduce "first-mover disadvantage" also known to economists as the "hungry penguin problem". As game theorist Michael Chwe points out, the fact that each person creates her report independently makes it less likely they'll later be accused of submitting copycat reports, if there are similarities between the incidents.

theodp writes: In an adapted excerpt from Geek Heresy: Rescuing Social Change from the Cult of Technology, Univ. of Michigan prof Kentaro Toyama begins: "'Technology is a game-changer in the field of education,'" Education Secretary Arne Duncan once said, and there was a time when I would have agreed. Over the last decade, I've built, used, and studied educational technology in countries around the world. As a computer scientist and former Microsoft employee, I wanted nothing more than to see innovation triumph in the classroom. But no matter how good the design, and despite rigorous tests of impact, I have never seen technology systematically overcome the socio-economic divides that exist in education. Children who are behind need high-quality adult guidance more than anything else. Many people believe that technology 'levels the playing field' of learning, but what I've discovered is that it does no such thing."

New submitter Desert Leap writes: The Washington Post reports a new study that suggests it is more environmentally friendly to fly rather than to drive. Analysis from the University of Michigan Transport Research Institute found that driving uses 57% more energy than flying per passenger mile. This is largely due to the number of occupied plane seats increasing while passengers per car decreased. Of course, "results may vary" for individual trips depending on many factors, such as distance flown (long flights are more fuel efficient) and the kind of car, and how many riders. One factoid is interesting: it takes 4,211 BTUs per person mile to drive. This number will fall as we switch over to electric vehicles. For example, a Tesla Model S takes about 1,100 BTUs per vehicle mile. Will future aircraft be able to also make the switch to electric?

New submitter cyberspittle sends this research report from the University of Michigan: An odd, iridescent material that's puzzled physicists for decades turns out to be an exotic state of matter that could open a new path to quantum computers and other next-generation electronics. ... The researchers provide the first direct evidence that samarium hexaboride, abbreviated SmB6, is a topological insulator (abstract). Topological insulators are, to physicists, an exciting class of solids that conduct electricity like a metal across their surface, but block the flow of current like rubber through their interior. They behave in this two-faced way despite that their chemical composition is the same throughout. ... This deeper understanding of samarium hexaboride raises the possibility that engineers might one day route the flow of electric current in quantum computers like they do on silicon in conventional electronics.

mpicpp sends news of research at the University of Michigan in which a self-assembling chain of particles can be used as tiny, electrically-activated muscles. The team started with particles similar to those found in paint, with diameters of about a hundredth the width of a strand of hair. They stretched these particles into football shapes and coated one side of each football with gold. The gilded halves attracted one another in slightly salty water—ideally about half the salt concentration in the sports drink Powerade. The more salt in the water, the stronger the attraction. Left to their own devices, the particles formed short chains of overlapping pairs, averaging around 50 or 60 particles to a chain. When exposed to an alternating electric field, the chains seemed to add new particles indefinitely. But the real excitement was in the way that the chains stretched. ... While the force generated by the fibers is about 1,000 times weaker than human muscle tissue per unit area, it may be enough for microbots.

theodp writes "The Motley Fool reports that the Data Scientists at LinkedIn have been playing with their Big Data, ranking schools based on how successful recent grads have been at landing desirable software development jobs. Here's their Top 25: CMU, Caltech, Cornell, MIT, Princeton, Berkeley, Univ. of Washington, Duke, Michigan, Stanford, UCLA, Illinois, UT Austin, Brown, UCSD, Harvard, Rice, Penn, Univ. of Arizona, Harvey Mudd, UT Dallas, San Jose State, USC, Washington University, RIT. There's also a shorter list for the best schools for software developers at startups, which draws a dozen schools from the previously mentioned schools, and adds Columbia, Univ. of Virginia, and Univ. of Maryland College Park. If you're in a position to actually hire new graduates, how much do you care about applicants' alma maters?

HughPickens.com writes Highway driving, which is less complex than city driving, has proved easy enough for self-driving cars, but busy downtown streets—where cars and pedestrians jockey for space and behave in confusing and surprising ways—are more problematic. Now Will Knight reports that Michigan's Department of Transportation and 13 companies involved with developing automated driving technology are constructing a 30-acre, $6.5 million driverless town near Ann Arbor to test self-driving cars in an urban environment. Complex intersections, confusing lane markings, and busy construction crews will be used to gauge the aptitude of the latest automotive sensors and driving algorithms and mechanical pedestrians will even leap into the road from between parked cars so researchers can see if they trip up onboard safety systems. "I think it's a great idea," says John Leonard, a professor at MIT who led the development of a self-driving vehicle for a challenge run by DARPA in 2007. "It is important for us to try to collect statistically meaningful data about the performance of self-driving cars. Repeated operations—even in a small-scale environment—can yield valuable data sets for testing and evaluating new algorithms." The testing facility is part of broader work by the University of Michigan's Mobility Transformation Facility that will include putting up to 20,000 vehicles on southeastern Michigan roads. By 2021, Ann Arbor could become the first American city with a shared fleet of networked, driverless vehicles. "Ann Arbor will be seen as the leader in 21st century mobility," says Peter Sweatman, director of the U-M Transportation Research Institute. "We want to demonstrate fully driverless vehicles operating within the whole infrastructure of the city within an eight-year timeline and to show that these can be safe, effective and commercially successful."

HughPickens.com writes Highway driving, which is less complex than city driving, has proved easy enough for self-driving cars, but busy downtown streets—where cars and pedestrians jockey for space and behave in confusing and surprising ways—are more problematic. Now Will Knight reports that Michigan's Department of Transportation and 13 companies involved with developing automated driving technology are constructing a 30-acre, $6.5 million driverless town near Ann Arbor to test self-driving cars in an urban environment. Complex intersections, confusing lane markings, and busy construction crews will be used to gauge the aptitude of the latest automotive sensors and driving algorithms and mechanical pedestrians will even leap into the road from between parked cars so researchers can see if they trip up onboard safety systems. "I think it's a great idea," says John Leonard, a professor at MIT who led the development of a self-driving vehicle for a challenge run by DARPA in 2007. "It is important for us to try to collect statistically meaningful data about the performance of self-driving cars. Repeated operations—even in a small-scale environment—can yield valuable data sets for testing and evaluating new algorithms." The testing facility is part of broader work by the University of Michigan's Mobility Transformation Facility that will include putting up to 20,000 vehicles on southeastern Michigan roads. By 2021, Ann Arbor could become the first American city with a shared fleet of networked, driverless vehicles. "Ann Arbor will be seen as the leader in 21st century mobility," says Peter Sweatman, director of the U-M Transportation Research Institute. "We want to demonstrate fully driverless vehicles operating within the whole infrastructure of the city within an eight-year timeline and to show that these can be safe, effective and commercially successful."

Almost a year ago you had a chance to ask professor Kevin Fu about medical device security. A number of events (including the collapse of his house) conspired to delay the answering of those questions. Professor Fu has finally found respite from calamity, coincidentally at a time when the FDA has issued guidance on the security of medical devices. Below you'll find his answers to your old but not forgotten questions. Fu: I apologize for the year-long delay, but my queue has rather overflowed after part of my house collapsed. See slide #11 for more information on the delay.

Medical device security is a challenging area because it covers a rather large set of disciplines including software engineering, clinical care, patient safety, electrical engineering, human factors, physiology, regulatory affairs, cryptography, etc. There are a lot of well meaning security engineers who have not yet mastered the culture and principles of health care and medicine, and similarly there are a lot of well meaning medical device manufacturers who have not yet mastered the culture and principles of information security and privacy. I started out as a gopher handing out authentication tokens for a paperless medical record system at a hospital in the early 1990s, but in the last decade have focused my attention on security of embedded devices with application to health and wellness.

I huddled with graduate students from my SPQR Lab at Michigan, and we wrote up the following responses to the great questions. We were not able to answer every question, but readers can find years worth of in-depth technical papers on blog.secure-medicine.org and spqr.eecs.umich.edu/publications.php and thaw.org.



Cochlear Implants
by mcspoo

How secure are Cochlear implants and their processors? Any chance I'm going to hear the voice of God (without the tooth implant, ala Real Genius?)

Fu: Classic cochlear implants are mostly analog circuits with some external supporting software. However, newer implants on the drawing board are looking at how to enable audiologists to adjust implant settings remotely from the cloud. There are, of course, some significant security and privacy issues that need to be resolved. But there are also good reasons for remote access. Namely, patient's bodies change overtime and an audiologist must tune the implant settings manually today. Remote control may simplify the life for patients from a demographic that may have difficulty making office visits.

Cochlear implants are amazing little devices to enable profoundly deaf patients to partially restore hearing. See the cover of Biodesign: The Process of Innovating Medical Technologies by Zenios, Makower, Yock. Also see Ultra Low Power Bioelectronics by Rahul Sarpeshkar. Cochlear implants consist of two major pieces: (1) an implant in the skull that directly stimulates the auditory nerve, and (2) a less resource-constrained external device worn on the scalp. The external device clips onto the scalp with a magnet to keep the implant paired. Think of the implant as special circuitry to wirelessly deliver sound as electrical impulses. Think of the external device as the source of power, sound inputs, and control.

I met a relatively young flight attendant a few years ago who had a cochlear implant. He explained that one day he suffered a routine cold that got worse and caused a rare infection that destroyed his auditory nerve. He lost his hearing. The cochlear implant sufficiently restored his hearing such that he and I could have a normal conversation.

You can imagine the complex security and privacy questions that will need to be considered when future devices go all "Internet of Things" or "TerraSwarm."



PCA Pumps?
by Digital Ebola

Have you explored changing the dosages on drug pumps? Either through exploiting the device directly or by exploiting the database backend? I reference the Hospira pumps that run Linux, allowing one to telnet to them as root with no password authentication. Hospira did issue an update to that but since pumps are so numerous, I'm sure that many hospitals have been slow to update. Thanks!

Fu: Pumps for medicine are amazing. Most people who have visited a hospital or seen a TV show should be aware of the plain old IV drip of saline solution to hydrate patients by gravity. It gets more interesting when a computer-controlled pump takes over from gravity. There are all sorts of pumps ranging from bed-side pumps to implantable pumps.

A PCA pump is short for a patient-controlled analgesia. I believe this question is referring to a bed-side pump rather than an implant. For instance, a patient may receive a PCA pump to deliver controlled pain medication such as morphine. Typical user interfaces consist of a "more please" button that delivers a bolus of drug via an IV.

A number of researchers have analyzed the attack surfaces for insulin infusion pumps, a special kind of externally worn pump for diabetics. Several faculty have done outstanding work in this space several years ago, and more recently a number of smart blackhat researchers have demonstrated the problems in ways more easily understandable by the general public. I think it's fair to say that manufacturers initially underestimated the importance of security requirements engineering during the early concept phases of product engineering. That said, the manufacturers are doing some amazing engineering. There is a game of catch-up, but I am optimistic that the manufacturers will improve by following the new U.S. FDA guidance on cybersecurityin good faith. Some manufacturers apparently have been thinking about security for a while. For instance, members of the insulin pump team at Medtronic recently were issued a medical device security patent filed way back in 2007!

Now on to the real question: what about the backdoor of the pump? No one likes to advertise the unsavory backdoors built into products---some by design and some by accident. It's out of sight, out of mind. On old CAT scans, you'll sometimes even find an "lp" Unix account enabled without a password. I don't know about this particular pump in question, but I would not be surprised if there are some ports left open for debugging or communication with online drug libraries. You will likely find some interesting traffic, perhaps not cryptographically protected, if you listen to the network. If you do find a problem, please be responsible and patient. Finding a vulnerability in a web browser is significantly different from finding a vulnerability in a medical device. The direct consequences on patients must be taken into account, and security researchers not collaborating with a physician are likely skating on thin ice. I recommend that researchers notify the FDA so that they may communicate the problem to the manufacturer. Call up the FDA people listed on the FDA cybersecurity guidance. Or file a MedWatch 3500 report. It once took a year for FDA to process one of my security reports; they are somewhat understaffed. FDA has tens of thousands of employees, but only about two of them focus on security. So be patient. They are good people doing the best they can with their scare resources. Remember, your U.S. readers elected the people who set the budget.



Clinical Data Systems
by DeathGrippe

Most clinics, hospitals, insurance companies and dental offices are extensively computerized and networked. Based on your experience, how often are these systems compromised?

Fu: I find a good rule of thumb to measure security of a clinical environment: count the number of Windows XP boxes. Why? Because these devices are more vulnerable to run-of-the-mill, conventional malware. At one large hospital, medical devices based on Windows XP were re-infected about every 12 days if the box is not protected. With "bandaid" approaches like firewalls and anti-virus, the devices can last longer before re-infection. Alas, you can't make good wine out of bad grapes. Windows XP lacks meaningful security requirements. Microsoft learned its lessons, and has improved the security requirements and approaches over the years. Microsoft ended all support for XP on April 8th of this year.

That said, Linux ain't no picnic either. All operating systems have risks and benefits. I believe the root of the problem is that software security lifecycles for consumer grade operating systems do not align well with the product lifecycles of medical devices. Medical devices need to remain safe and effective for a very long time.



What can I do if I have one?
by AmiMoJo

Say I have an implant that could be hacked, what can I do to protect myself? Are any vendors more reputable than others when it comes to security? Is tinfoil effective? Should I demand my doctor replaces known vulnerable equipment?

Fu: I think patients can take comfort in knowing that FDA has written meaningful guidance on cybersecurity that is likely a game changer for manufacturing. Also, I find that engineers at most medical device manufactures sincerely want to improve the security of their products. This positive attitude is unlike what one will find in adversarial industries like electronic voting where it's more common to see manufacturer denial of risks rather than mitigation risks. I've seen some large medical device manufacturers vendors organize security teams composed of dozens of employees across engineering, sales, marketing, you name it, the whole company. They are beginning to understand that information security and privacy has to become part of the corporate culture if the products make use of modern communication and computer technology.

On the other hand, I don't think you'll ever find a hack-proof computer---whether it be a laptop, smart fridge, or medical device. I used to believe that a computer buried in concrete was secure, until I buried one in the concrete foundation of my house and powered it up wirelessly. You could also go to your car dealer and replace your car with a crash-proof car after you run into a tree. You might get funny looks. A manufacturer cannot eliminate risk, but it can be smart about minimizing risk. For instance, one of the best ways to minimize security risk is to have meaningful security requirements during the concept phase of device engineering. The requirements won't prevent security problems, but lack of security requirements will prevent the product from having meaningful security down the line. One can argue that it's a lot cheaper to engineer security from the start rather than to retrofit, but that argument is no longer necessary since draft FDA guidance on cybersecurity is abundantly clear on expectations for security risk management during the manufacture of new devices.

If I were prescribed a medical device, I would accept it. Why? Anything with a computer is hackable by some adversary. So worrying about whether an implant can being hacked does not help answer the basic question: how to balance risk. If you are prescribed a medical device, then likely your doctor determined that you have a significant, predisposed risk. For instance, you might have a significant risk of sudden cardiac arrest. In general, you are much safer with a device than without.



Re:Start-ups
by Anonymous Coward

How good is malwaresoftware and the WattsUpDoc system at finding something potentially harmful on a device?

Fu: WattsUpDoc is a system that detects malware by analyzing patterns in the power outlet. It's basically a phase shift on the AC power line caused by reactive power and varying loads of the connected computer. The details get hairy and are written for the experts, so I'd refer you to the scientific paper. The beauty is that no software changes are required for the device being monitored (e.g., medical devices).

We published our report on WattsUpDoc at the USENIX HealthTech workshop. There is also a related paper on detecting web browser activity from the power lines. The performance surprised me: 95% accuracy for known malware, and 85% accuracy for previously unknown malware (unlabeled samples of a malware infection that were not in the training set). It works well because medical devices tend to do a small number of different things when working normally. We can detect the deviation.



Should the local IT team have full control over a system
by Joe_Dragon

Should the local IT team have full control over any system in place / should vendors be forced to let systems have AV and OS updates installed on them with out delays?

Fu: Hi Joe the Dragon. I shall call you Trogdor This is a good question, but it technically is a leading question because computing systems created by medical device manufacturers force the IT team to choose between bad and worse. In a more ideal world, we wouldn't need to worry about viruses in the first place. So let me go on a tangent for a moment. Buffer overflows? Maybe that medical device should not be written in C. SQL injection error? Maybe you shouldn't be running a web server with an embedded database inside a life-critical medical device in the first place. The IT folks catch a lot of blame ranging from breaches to clinician complaints of mucking up the clinical workflow. There's some truth to that, but realize that the IT folks are stuck with what they can buy or make.

Ok, now your question: Do you give IT the keys? I'm not gonna be tricked into answering that one. It depends. I think the most effective organizational structures are ones where the clinical safety teams and the IT security teams learn to speak each others' languages. The manufacturers need to be forthcoming about offering regular security updates for underlying 3rd party software if they make the business choice to use COTS software. Hey, COTS software is cheap for a reason. The best situation is when the leaders of these teams do not hesitate to call each other. That said, the most secure system might also be the most unsafe. The most safe system might be the least secure. There are cases where one might forgo security because a safety issue trumps. What if you lock out access to a hypothetical pacemaker after three failed password attempts? Probably not a good idea if you think for a moment. A secure system that cannot deliver care is neither safe nor effective. Striking the balance is tricky.

I have a long rant on software updates (NSFW).



Safer Programming Language
by Anonymous Coward

The C programming language is most often used for embedded devices. The language is poorly specified. Compilers sometimes have issues, and programmers find a zillion creative ways to make mistakes. MISRA C and its enforcement is a bag of hurt in the absence of certified tools. Has there been any work to define a more safe/sane programming language for embedded devices?

Fu: Yes, but it's certainly hard to find in the medical device community. My colleagues from aviation software safety brag about their safer languages and practices, and I do think it's a good idea for the medical device community to borrow ideas from avionics. However, there are a couple roadblocks.

First, there's a crapton of legacy software out there. Try this experiment: walk into the C suite (not the programming language, the corporate suite), then declare that you need to stop product development for 9 months in order to convert to architectures that have better security properties. I know of only one company that did this (hint, it's an automotive company).

Second, the universities are at fault. I once asked a senior engineer at a medical device manufacturer why they wrote in C and assembly for their implantable medical device firmware. The engineer explained, that's who they can hire! The universities produce the graduates, and we are not training them sufficiently for trustworthy computing. When we teach students C and C++, we are handing them loaded weapons. Many of the students are talented and can respect the unchecked power of C and assembly. It's especially good for high performance systems and hand-optimized inner loop code. However, if we want to see improvements in choices of programming languages, universities need to produce engineers who understand the risks of different programming languages. No one language is perfect for every situation. I highly recommend reading Prof. John Knight's book on Fundamentals of Dependable Computing for Software Engineers to learn about how to match the programming language to the risks.



What to do when security is unfixable?
by Anonymous Coward

Seeing the abysmal state of computer security, even basic computer reliability expectations (which Dijkstra already noted, years ago), it's no surprise that embedded systems are no better. Simply because you usually don't see them and are thus less likely to notice just how poorly and insecurely the software is done. So how do we convince these people in the medical apparatus industry to leave well alone with the networking and wireless and bells and whistles, and simply deliver us machinery that does what it does, keep us alive, and not also surf the 'web for cat videos, or leave the door open for someone to come along with the latest exploit kit? Why do these things have to be connected at all?

Fu: A couple responses. A lot of medical devices are not networked in the sense of our home computers on the Internet. Many are connected with sneakernet. Yet the malware still can get in. Sleep labs are notorious for malware because patients bring in USB sticks of music, plus unwanted bonus material. I know one large medical device that was offline, but got infected by Conficker during the split second that the vendor temporarily enabled the Internet connection to download a software update. Sad.

Keep in mind that manufacturers create products because they think they can sell them. If consumers did not express interest in questionably secure products, then we'd see better security. If insurance rates were tied to cybersecurity hygiene, we'd see security economics at work. Unfortunately, security and privacy are out of sight and out of mind as you point out. For instance, hospitals often demand the bells and whistles. I witnessed one physician checking Gmail and the web on a medical records system during surgery. I didn't have a chance to explain the risks of drive-by downloads as he was occupied teaching a young resident how to catheterize the anesthetized patient. I know another hospital system where they let radiologists check email on the medical devices because staff wanted access to email, and there wasn't enough desk space for a second computer.

I have a set of slides on wireless where I make the argument that wireless is like bacon. People think it makes everything taste better. Wireless communication and network connections do serve an important role, but one needs to make a case-by-case judgement for each device. I like the concept of wireless to reduce infection rates during surgical implantations of defibrillators and pacemakers. About 1-2% of implantations result in major complications such as infection, and about 1% of these cases are fatal. Wireless does introduce security risks. While the security architectures can be greatly improved, I'd rather be insecurely alive than securely dead from an infection.



Medical device security vs. Open standards?
by Anonymous Coward

In the ever increasing world of consumerized technology (Apps, smartphones, smarter cars etc.), how do you see medical device security staying relevant and cutting edge while maintaining adequate security? More and more people can and probably will ask "why can't I use with my ?". For instance,could a secure, but open interface be created for Insulin pumps which would allow an end-user app to aggregate multiple data sources into a better snapshot of that person, while still being secure and protected from hijacking by a 3rd party?

Fu: I agree that the natives will get restless if they perceive security as a problem rather than a solution. However, consumers have become accustomed to crap in a hurry during the 1990s transition from postcards to hyperconnected electronic communication. I think it will be difficult to create magic walled gardens or magic interfaces that "add" security because security is not a product, it's a property and a process. I see three areas where one can improve the trustworthiness of medical device software: early concept phases, post market surveillance, and all the fun stuff between (design, implementation, testing, verification, validation, etc.). There's a significant security focus on the implementation and finding bugs, but by that time much of the fate is sealed by the requirements engineering. I think more time should be spent at the concept phase on hazard analysis, risk management, etc. so that implementations are less likely to have security problems. Then spend time on post-market surveillance so you can measure the shifting effectiveness of the security mechanisms as the threats evolve.

Today, the worries are mostly conventional malware slowing down medical devices or causing malfunctions. We've begun to see signs of nation state threats, and we should use our time carefully as threats rarely decrease in severity.

I'd encourage computer science students to work for a medical device manufacturer or FDA rather than the latest Silicon Valley startup. The problems will be interesting and will bring great personal satisfaction. For creative students who enjoy writing and open ended problem solving in health care, apply to graduate schools that carry out medical device security research! Best wishes.

Almost a year ago you had a chance to ask professor Kevin Fu about medical device security. A number of events (including the collapse of his house) conspired to delay the answering of those questions. Professor Fu has finally found respite from calamity, coincidentally at a time when the FDA has issued guidance on the security of medical devices. Below you'll find his answers to your old but not forgotten questions. Fu: I apologize for the year-long delay, but my queue has rather overflowed after part of my house collapsed. See slide #11 for more information on the delay.

Medical device security is a challenging area because it covers a rather large set of disciplines including software engineering, clinical care, patient safety, electrical engineering, human factors, physiology, regulatory affairs, cryptography, etc. There are a lot of well meaning security engineers who have not yet mastered the culture and principles of health care and medicine, and similarly there are a lot of well meaning medical device manufacturers who have not yet mastered the culture and principles of information security and privacy. I started out as a gopher handing out authentication tokens for a paperless medical record system at a hospital in the early 1990s, but in the last decade have focused my attention on security of embedded devices with application to health and wellness.

I huddled with graduate students from my SPQR Lab at Michigan, and we wrote up the following responses to the great questions. We were not able to answer every question, but readers can find years worth of in-depth technical papers on blog.secure-medicine.org and spqr.eecs.umich.edu/publications.php and thaw.org.



Cochlear Implants
by mcspoo

How secure are Cochlear implants and their processors? Any chance I'm going to hear the voice of God (without the tooth implant, ala Real Genius?)

Fu: Classic cochlear implants are mostly analog circuits with some external supporting software. However, newer implants on the drawing board are looking at how to enable audiologists to adjust implant settings remotely from the cloud. There are, of course, some significant security and privacy issues that need to be resolved. But there are also good reasons for remote access. Namely, patient's bodies change overtime and an audiologist must tune the implant settings manually today. Remote control may simplify the life for patients from a demographic that may have difficulty making office visits.

Cochlear implants are amazing little devices to enable profoundly deaf patients to partially restore hearing. See the cover of Biodesign: The Process of Innovating Medical Technologies by Zenios, Makower, Yock. Also see Ultra Low Power Bioelectronics by Rahul Sarpeshkar. Cochlear implants consist of two major pieces: (1) an implant in the skull that directly stimulates the auditory nerve, and (2) a less resource-constrained external device worn on the scalp. The external device clips onto the scalp with a magnet to keep the implant paired. Think of the implant as special circuitry to wirelessly deliver sound as electrical impulses. Think of the external device as the source of power, sound inputs, and control.

I met a relatively young flight attendant a few years ago who had a cochlear implant. He explained that one day he suffered a routine cold that got worse and caused a rare infection that destroyed his auditory nerve. He lost his hearing. The cochlear implant sufficiently restored his hearing such that he and I could have a normal conversation.

You can imagine the complex security and privacy questions that will need to be considered when future devices go all "Internet of Things" or "TerraSwarm."



PCA Pumps?
by Digital Ebola

Have you explored changing the dosages on drug pumps? Either through exploiting the device directly or by exploiting the database backend? I reference the Hospira pumps that run Linux, allowing one to telnet to them as root with no password authentication. Hospira did issue an update to that but since pumps are so numerous, I'm sure that many hospitals have been slow to update. Thanks!

Fu: Pumps for medicine are amazing. Most people who have visited a hospital or seen a TV show should be aware of the plain old IV drip of saline solution to hydrate patients by gravity. It gets more interesting when a computer-controlled pump takes over from gravity. There are all sorts of pumps ranging from bed-side pumps to implantable pumps.

A PCA pump is short for a patient-controlled analgesia. I believe this question is referring to a bed-side pump rather than an implant. For instance, a patient may receive a PCA pump to deliver controlled pain medication such as morphine. Typical user interfaces consist of a "more please" button that delivers a bolus of drug via an IV.

A number of researchers have analyzed the attack surfaces for insulin infusion pumps, a special kind of externally worn pump for diabetics. Several faculty have done outstanding work in this space several years ago, and more recently a number of smart blackhat researchers have demonstrated the problems in ways more easily understandable by the general public. I think it's fair to say that manufacturers initially underestimated the importance of security requirements engineering during the early concept phases of product engineering. That said, the manufacturers are doing some amazing engineering. There is a game of catch-up, but I am optimistic that the manufacturers will improve by following the new U.S. FDA guidance on cybersecurityin good faith. Some manufacturers apparently have been thinking about security for a while. For instance, members of the insulin pump team at Medtronic recently were issued a medical device security patent filed way back in 2007!

Now on to the real question: what about the backdoor of the pump? No one likes to advertise the unsavory backdoors built into products---some by design and some by accident. It's out of sight, out of mind. On old CAT scans, you'll sometimes even find an "lp" Unix account enabled without a password. I don't know about this particular pump in question, but I would not be surprised if there are some ports left open for debugging or communication with online drug libraries. You will likely find some interesting traffic, perhaps not cryptographically protected, if you listen to the network. If you do find a problem, please be responsible and patient. Finding a vulnerability in a web browser is significantly different from finding a vulnerability in a medical device. The direct consequences on patients must be taken into account, and security researchers not collaborating with a physician are likely skating on thin ice. I recommend that researchers notify the FDA so that they may communicate the problem to the manufacturer. Call up the FDA people listed on the FDA cybersecurity guidance. Or file a MedWatch 3500 report. It once took a year for FDA to process one of my security reports; they are somewhat understaffed. FDA has tens of thousands of employees, but only about two of them focus on security. So be patient. They are good people doing the best they can with their scare resources. Remember, your U.S. readers elected the people who set the budget.



Clinical Data Systems
by DeathGrippe

Most clinics, hospitals, insurance companies and dental offices are extensively computerized and networked. Based on your experience, how often are these systems compromised?

Fu: I find a good rule of thumb to measure security of a clinical environment: count the number of Windows XP boxes. Why? Because these devices are more vulnerable to run-of-the-mill, conventional malware. At one large hospital, medical devices based on Windows XP were re-infected about every 12 days if the box is not protected. With "bandaid" approaches like firewalls and anti-virus, the devices can last longer before re-infection. Alas, you can't make good wine out of bad grapes. Windows XP lacks meaningful security requirements. Microsoft learned its lessons, and has improved the security requirements and approaches over the years. Microsoft ended all support for XP on April 8th of this year.

That said, Linux ain't no picnic either. All operating systems have risks and benefits. I believe the root of the problem is that software security lifecycles for consumer grade operating systems do not align well with the product lifecycles of medical devices. Medical devices need to remain safe and effective for a very long time.



What can I do if I have one?
by AmiMoJo

Say I have an implant that could be hacked, what can I do to protect myself? Are any vendors more reputable than others when it comes to security? Is tinfoil effective? Should I demand my doctor replaces known vulnerable equipment?

Fu: I think patients can take comfort in knowing that FDA has written meaningful guidance on cybersecurity that is likely a game changer for manufacturing. Also, I find that engineers at most medical device manufactures sincerely want to improve the security of their products. This positive attitude is unlike what one will find in adversarial industries like electronic voting where it's more common to see manufacturer denial of risks rather than mitigation risks. I've seen some large medical device manufacturers vendors organize security teams composed of dozens of employees across engineering, sales, marketing, you name it, the whole company. They are beginning to understand that information security and privacy has to become part of the corporate culture if the products make use of modern communication and computer technology.

On the other hand, I don't think you'll ever find a hack-proof computer---whether it be a laptop, smart fridge, or medical device. I used to believe that a computer buried in concrete was secure, until I buried one in the concrete foundation of my house and powered it up wirelessly. You could also go to your car dealer and replace your car with a crash-proof car after you run into a tree. You might get funny looks. A manufacturer cannot eliminate risk, but it can be smart about minimizing risk. For instance, one of the best ways to minimize security risk is to have meaningful security requirements during the concept phase of device engineering. The requirements won't prevent security problems, but lack of security requirements will prevent the product from having meaningful security down the line. One can argue that it's a lot cheaper to engineer security from the start rather than to retrofit, but that argument is no longer necessary since draft FDA guidance on cybersecurity is abundantly clear on expectations for security risk management during the manufacture of new devices.

If I were prescribed a medical device, I would accept it. Why? Anything with a computer is hackable by some adversary. So worrying about whether an implant can being hacked does not help answer the basic question: how to balance risk. If you are prescribed a medical device, then likely your doctor determined that you have a significant, predisposed risk. For instance, you might have a significant risk of sudden cardiac arrest. In general, you are much safer with a device than without.



Re:Start-ups
by Anonymous Coward

How good is malwaresoftware and the WattsUpDoc system at finding something potentially harmful on a device?

Fu: WattsUpDoc is a system that detects malware by analyzing patterns in the power outlet. It's basically a phase shift on the AC power line caused by reactive power and varying loads of the connected computer. The details get hairy and are written for the experts, so I'd refer you to the scientific paper. The beauty is that no software changes are required for the device being monitored (e.g., medical devices).

We published our report on WattsUpDoc at the USENIX HealthTech workshop. There is also a related paper on detecting web browser activity from the power lines. The performance surprised me: 95% accuracy for known malware, and 85% accuracy for previously unknown malware (unlabeled samples of a malware infection that were not in the training set). It works well because medical devices tend to do a small number of different things when working normally. We can detect the deviation.



Should the local IT team have full control over a system
by Joe_Dragon

Should the local IT team have full control over any system in place / should vendors be forced to let systems have AV and OS updates installed on them with out delays?

Fu: Hi Joe the Dragon. I shall call you Trogdor This is a good question, but it technically is a leading question because computing systems created by medical device manufacturers force the IT team to choose between bad and worse. In a more ideal world, we wouldn't need to worry about viruses in the first place. So let me go on a tangent for a moment. Buffer overflows? Maybe that medical device should not be written in C. SQL injection error? Maybe you shouldn't be running a web server with an embedded database inside a life-critical medical device in the first place. The IT folks catch a lot of blame ranging from breaches to clinician complaints of mucking up the clinical workflow. There's some truth to that, but realize that the IT folks are stuck with what they can buy or make.

Ok, now your question: Do you give IT the keys? I'm not gonna be tricked into answering that one. It depends. I think the most effective organizational structures are ones where the clinical safety teams and the IT security teams learn to speak each others' languages. The manufacturers need to be forthcoming about offering regular security updates for underlying 3rd party software if they make the business choice to use COTS software. Hey, COTS software is cheap for a reason. The best situation is when the leaders of these teams do not hesitate to call each other. That said, the most secure system might also be the most unsafe. The most safe system might be the least secure. There are cases where one might forgo security because a safety issue trumps. What if you lock out access to a hypothetical pacemaker after three failed password attempts? Probably not a good idea if you think for a moment. A secure system that cannot deliver care is neither safe nor effective. Striking the balance is tricky.

I have a long rant on software updates (NSFW).



Safer Programming Language
by Anonymous Coward

The C programming language is most often used for embedded devices. The language is poorly specified. Compilers sometimes have issues, and programmers find a zillion creative ways to make mistakes. MISRA C and its enforcement is a bag of hurt in the absence of certified tools. Has there been any work to define a more safe/sane programming language for embedded devices?

Fu: Yes, but it's certainly hard to find in the medical device community. My colleagues from aviation software safety brag about their safer languages and practices, and I do think it's a good idea for the medical device community to borrow ideas from avionics. However, there are a couple roadblocks.

First, there's a crapton of legacy software out there. Try this experiment: walk into the C suite (not the programming language, the corporate suite), then declare that you need to stop product development for 9 months in order to convert to architectures that have better security properties. I know of only one company that did this (hint, it's an automotive company).

Second, the universities are at fault. I once asked a senior engineer at a medical device manufacturer why they wrote in C and assembly for their implantable medical device firmware. The engineer explained, that's who they can hire! The universities produce the graduates, and we are not training them sufficiently for trustworthy computing. When we teach students C and C++, we are handing them loaded weapons. Many of the students are talented and can respect the unchecked power of C and assembly. It's especially good for high performance systems and hand-optimized inner loop code. However, if we want to see improvements in choices of programming languages, universities need to produce engineers who understand the risks of different programming languages. No one language is perfect for every situation. I highly recommend reading Prof. John Knight's book on Fundamentals of Dependable Computing for Software Engineers to learn about how to match the programming language to the risks.



What to do when security is unfixable?
by Anonymous Coward

Seeing the abysmal state of computer security, even basic computer reliability expectations (which Dijkstra already noted, years ago), it's no surprise that embedded systems are no better. Simply because you usually don't see them and are thus less likely to notice just how poorly and insecurely the software is done. So how do we convince these people in the medical apparatus industry to leave well alone with the networking and wireless and bells and whistles, and simply deliver us machinery that does what it does, keep us alive, and not also surf the 'web for cat videos, or leave the door open for someone to come along with the latest exploit kit? Why do these things have to be connected at all?

Fu: A couple responses. A lot of medical devices are not networked in the sense of our home computers on the Internet. Many are connected with sneakernet. Yet the malware still can get in. Sleep labs are notorious for malware because patients bring in USB sticks of music, plus unwanted bonus material. I know one large medical device that was offline, but got infected by Conficker during the split second that the vendor temporarily enabled the Internet connection to download a software update. Sad.

Keep in mind that manufacturers create products because they think they can sell them. If consumers did not express interest in questionably secure products, then we'd see better security. If insurance rates were tied to cybersecurity hygiene, we'd see security economics at work. Unfortunately, security and privacy are out of sight and out of mind as you point out. For instance, hospitals often demand the bells and whistles. I witnessed one physician checking Gmail and the web on a medical records system during surgery. I didn't have a chance to explain the risks of drive-by downloads as he was occupied teaching a young resident how to catheterize the anesthetized patient. I know another hospital system where they let radiologists check email on the medical devices because staff wanted access to email, and there wasn't enough desk space for a second computer.

I have a set of slides on wireless where I make the argument that wireless is like bacon. People think it makes everything taste better. Wireless communication and network connections do serve an important role, but one needs to make a case-by-case judgement for each device. I like the concept of wireless to reduce infection rates during surgical implantations of defibrillators and pacemakers. About 1-2% of implantations result in major complications such as infection, and about 1% of these cases are fatal. Wireless does introduce security risks. While the security architectures can be greatly improved, I'd rather be insecurely alive than securely dead from an infection.



Medical device security vs. Open standards?
by Anonymous Coward

In the ever increasing world of consumerized technology (Apps, smartphones, smarter cars etc.), how do you see medical device security staying relevant and cutting edge while maintaining adequate security? More and more people can and probably will ask "why can't I use with my ?". For instance,could a secure, but open interface be created for Insulin pumps which would allow an end-user app to aggregate multiple data sources into a better snapshot of that person, while still being secure and protected from hijacking by a 3rd party?

Fu: I agree that the natives will get restless if they perceive security as a problem rather than a solution. However, consumers have become accustomed to crap in a hurry during the 1990s transition from postcards to hyperconnected electronic communication. I think it will be difficult to create magic walled gardens or magic interfaces that "add" security because security is not a product, it's a property and a process. I see three areas where one can improve the trustworthiness of medical device software: early concept phases, post market surveillance, and all the fun stuff between (design, implementation, testing, verification, validation, etc.). There's a significant security focus on the implementation and finding bugs, but by that time much of the fate is sealed by the requirements engineering. I think more time should be spent at the concept phase on hazard analysis, risk management, etc. so that implementations are less likely to have security problems. Then spend time on post-market surveillance so you can measure the shifting effectiveness of the security mechanisms as the threats evolve.

Today, the worries are mostly conventional malware slowing down medical devices or causing malfunctions. We've begun to see signs of nation state threats, and we should use our time carefully as threats rarely decrease in severity.

I'd encourage computer science students to work for a medical device manufacturer or FDA rather than the latest Silicon Valley startup. The problems will be interesting and will bring great personal satisfaction. For creative students who enjoy writing and open ended problem solving in health care, apply to graduate schools that carry out medical device security research! Best wishes.

An anonymous reader writes For the fifth consecutive year, the solar car team from the University of Michigan has won the American Solar Car Challenge. The event is an eight-day, 1,700-mile race with a total of 23 participating teams. The Umich victory comes in spite of a 20-30 minute delay when they had problems with the motor at the very beginning of the race. "They made the time up when team strategists decided to push the car to the speed limit while the sun was shining bright, rather than hold back to conserve energy." Footage of the race and daily updates on the car's performance are available from the team's website, as are the specs of the car itself. Notably, the current iteration of the car weighs only 320 pounds, a full 200 pounds lighter than the previous version.

An anonymous reader writes For the fifth consecutive year, the solar car team from the University of Michigan has won the American Solar Car Challenge. The event is an eight-day, 1,700-mile race with a total of 23 participating teams. The Umich victory comes in spite of a 20-30 minute delay when they had problems with the motor at the very beginning of the race. "They made the time up when team strategists decided to push the car to the speed limit while the sun was shining bright, rather than hold back to conserve energy." Footage of the race and daily updates on the car's performance are available from the team's website, as are the specs of the car itself. Notably, the current iteration of the car weighs only 320 pounds, a full 200 pounds lighter than the previous version.

An anonymous reader writes For the fifth consecutive year, the solar car team from the University of Michigan has won the American Solar Car Challenge. The event is an eight-day, 1,700-mile race with a total of 23 participating teams. The Umich victory comes in spite of a 20-30 minute delay when they had problems with the motor at the very beginning of the race. "They made the time up when team strategists decided to push the car to the speed limit while the sun was shining bright, rather than hold back to conserve energy." Footage of the race and daily updates on the car's performance are available from the team's website, as are the specs of the car itself. Notably, the current iteration of the car weighs only 320 pounds, a full 200 pounds lighter than the previous version.

Lauro Ojeda is a researcher at the University of Michigan who also works with a Korean company, Microinfinity, that says it works with everything "from basic sensors to full navigation systems, and is becoming the world leading navigation system company." Prof. Ojeda also has a personal website, robotnav.com, where he posts his navigation and control code (under an open source license, of course) that you are welcome to download, play with, install on any suitable device you have handy, and modify at will. A lot of his work is with Lego-based robots because they're both inexpensive and readily available almost anywhere. If you already have a good-sized Lego collection, you probably only need a few pieces to follow or even surpass Prof. Ojeda's work. And who knows? If you manage to make an autonomous Lego robot, your next stage may be a car that drives itself so you can watch SyFy reruns on your way to work instead of worrying about the truck in the left lane that looks like it's about to make a right turn.

Kevin Fu is a professor of electrical engineering and computer science at the University of Michigan. He heads a research group on medical-device security, Archimedes, that works to find vulnerabilities in medical equipment. WattsUpDoc, a system that can detect malware on medical devices by monitoring changes in power consumption, is based on his work. Professor Fu has agreed to put down the pacemakers for a moment and answer your questions about his work and medical device security in general. As usual, ask as many as you'd like, but please, one question per post.

SustainableJeroen writes "On October 6th, the 2013 World Solar Challenge will start. This year, 43 teams (more than ever before) from 24 countries around the world will compete in this biannual 3000 km road event, which runs from Darwin to Adelaide. In both 2009 and 2011, Tokai University (Japan), Nuon Solar Team (the Netherlands) and University of Michigan Solar Car Team (USA) finished in first, second and third position, respectively. Who will win this year? We'll know for sure on October 13th, the end of the event. Team details (photos, car specifications, links to websites) can be found here."

cylonlover writes "A team of engineering researchers at the University of Michigan has developed a nanoscale coating that causes almost all liquids to bounce off surfaces treated with it. Creating a surface structure that is least 95 percent air, the new 'superomniphobic' coating is claimed to repel the broadest range of liquids of any material in its class, opening up the possibility of super stain-resistant clothing, drag-reducing waterproof paints for ship hulls, breathable garments that provide protection from harmful chemicals, and touchscreens resistant to fingerprint smudges."

chicksdaddy writes "The University of Michigan will be among the first to offer graduate students the opportunity to study the security of advanced medical devices. The course, EECS 598-008 'Medical Device Security' will teach graduate students in UMich's Electrical Engineering and Computer Science program 'the engineering concepts and skills for creating more trustworthy software-based medical devices ranging from pacemakers to radiation planning software to mobile medical apps.' The new course comes amid rapid change in the market for sophisticated medical devices like insulin pumps, respirators and monitoring stations, which increasingly run on versions of the same operating systems that power desktops and servers. In 2011, the U.S. Food and Drug Administration reported that software failures were the root cause of a quarter of all medical device recalls (PDF)."

Professor Lampe is using gamification in his 200-student lecture classes to make them more interesting. He says big-class lectures can often be as boring for the professor as they are for the students. A little bit of game-type action can spice things up and make classes more interesting. Near the end of the video he points out that gamification is becoming popular for employee training in private enterprise, so why not use the concept in universities and other educational institutions?

After watching this video, a lot of you are going to wish you were Dave Carter, who works at the University of Michigan's Computer and Video Game Archive. He deals with video games, from the oldest hand-helds and consoles to the newest Xbox and PC games and controllers. A lot of his time is no doubt spent fixing things that break, finding obscure games, being generally helpful, and making sure nobody breaks the games, consoles, computers, controllers, and even board games and memorabilia in the collection. But still, this has got to be the ultimate job for a game junkie. And it looks like a great place to visit, because this museum is part of a library, and just as a library encourages you to pick up books and read them, this is a place where you can actually play the games, not just stare at a ColecoVision console in a display case. You can play in a cubicle or, for games that take some space, there are a couple of big gaming rooms with soft-looking sofas and big flat-screen TVs, where you can jump up and down like crazy while you're doing Guitar Hero or using a Wii or Kinect. And if you can't make it to Ann Arbor, MI, there's an informative blog that's all about video games past and present that's must reading for almost any serious gamer.

After watching this video, a lot of you are going to wish you were Dave Carter, who works at the University of Michigan's Computer and Video Game Archive. He deals with video games, from the oldest hand-helds and consoles to the newest Xbox and PC games and controllers. A lot of his time is no doubt spent fixing things that break, finding obscure games, being generally helpful, and making sure nobody breaks the games, consoles, computers, controllers, and even board games and memorabilia in the collection. But still, this has got to be the ultimate job for a game junkie. And it looks like a great place to visit, because this museum is part of a library, and just as a library encourages you to pick up books and read them, this is a place where you can actually play the games, not just stare at a ColecoVision console in a display case. You can play in a cubicle or, for games that take some space, there are a couple of big gaming rooms with soft-looking sofas and big flat-screen TVs, where you can jump up and down like crazy while you're doing Guitar Hero or using a Wii or Kinect. And if you can't make it to Ann Arbor, MI, there's an informative blog that's all about video games past and present that's must reading for almost any serious gamer.

coondoggie writes "The U.S. Department of Transportation said it will run a massive road test of cars, trucks and buses linked together via WiFi equipment in what the agency says will be the largest test of automated crash avoidance technology to date. The test will be conducted by the University of Michigan's Transportation Research Institute (UMTRI), and feature mostly volunteer participants whose vehicles have been outfitted with vehicle-to-vehicle and vehicle-to-infrastructure communication devices."

itwbennett writes "Car-to-car communications is about to get its first large-scale, real-world test in Ann Arbor, Mich., where the University of Michigan's Transportation Research Institute will be putting as many as 3,000 cars equipped with short-range radio on the roads, thanks to a $14.9 million grant it just got from the U.S. Dept. of Transportation. DoT reports predict that up to 82 percent of serious accidents among unimpaired drivers can be eliminated or reduced by a little car-to-car negotiation, or an early warning that a sedan three cars ahead just hit the brakes even though you can't see it through the giant SUV directly in front of you."

Nrbelex writes "A team at the University of Michigan and Microsoft Research has uncovered, for the first time, the frequently suboptimal network practices of more than 100 cellular carriers. By recruiting almost 400 volunteers to run an app on their phones that probes a carrier's networks, the team discovered, for example, that one of the four major U.S. carriers is slowing its network performance by up to 50 percent (PDF). They also found carrier policies that drained users' phone batteries at an accelerated rate, and security vulnerabilities that could leave devices open to complete takeover by hackers."

MrSeb writes "Researchers at the University of Michigan have created a running, obstacle-scaling robot. This robot, which is called MABEL (not an acronym), is capable of running at speeds of up to 3.06 meters per second, or 6.8 mph. Physically she is very similar to a human — a heavy torso, and light, springed legs that act as load balancers and shock absorbers — and with a clever feedback system, MABEL even runs like a human, spending 40% of her time three or four inches off the ground."

An anonymous reader tips a University of Michigan news release about the creation of what's being called an "optical battery" that could lead to the use of solar power without traditional solar cells (abstract). Quoting: "Light has electric and magnetic components. Until now, scientists thought the effects of the magnetic field were so weak that they could be ignored. What Rand and his colleagues found is that at the right intensity, when light is traveling through a material that does not conduct electricity, the light field can generate magnetic effects that are 100 million times stronger than previously expected. Under these circumstances, the magnetic effects develop strength equivalent to a strong electric effect. 'This could lead to a new kind of solar cell without semiconductors and without absorption to produce charge separation,' Rand said. 'In solar cells, the light goes into a material, gets absorbed and creates heat. Here, we expect to have a very low heat load. Instead of the light being absorbed, energy is stored in the magnetic moment. Intense magnetization can be induced by intense light and then it is ultimately capable of providing a capacitive power source.'"

CWmike writes "Researchers at the University of Michigan announced Wednesday that they have created the first prototype for a millimeter-scale computing system that can hold up to a week's worth of data when implanted in something as small as a human eye. The computer, called the Phoenix chip, is just over one cubic millimeter in size and was designed to monitor eye pressure in glaucoma patients. 'This is the first true millimeter-scale complete computing system,' said Dennis Sylvester, a professor at the school and one of the researchers on the project. Within the computer is an ultra low-power microprocessor, a pressure sensor, memory, a thin-film battery, a solar cell and a wireless radio with an antenna that can transmit data to an external reader device held near the eye."

An anonymous reader writes "Researchers at the University of Michigan describe how to hijack the iPhone's headset port to power peripherals, establish bi-directional communications with them, and interface various sensors, all without jailbreaking your iPhone or having to pay thousands to access to the Apple Dock Connector. This makes it possible for students, hackers, and DIYers to extend the phone's functionality to the physical world. The team is giving away 20 HiJack modules/programmers to enable new apps."

An anonymous reader writes "US teams dominated the MAGIC 2010 autonomous robotics competition, mapping and neutralizing simulated bombs at the 250,000 sq. meter Royal Showgrounds in Adelaide, Australia. Leading the pack with a team of fourteen robots was Team Michigan, principally from the University of Michigan, followed by the University of Pennsylvania, and RASR. This contest marks the beginning of practical robots that not only think for themselves, but also actively coordinate with a human commander."

eldavojohn writes "We've only had evidence for three kinds of neutrinos so far, but a recent test at Fermilab involving an antineutrino beam has reinforced a Michigan researcher's earlier experiment suggesting a fourth flavor. What's really odd about this is that a prior neutrino test (carried out as part of project MiniBooNE) did not result in indications of such strange oscillations. According to the researcher, 'The simplest explanation involves adding new neutrino-like particles, or sterile neutrinos, which do not have the normal weak interactions.' But this could also be an unknown or misunderstood effect. A Los Alamos National Laboratory scientist added that an explanation of this strange anomaly could result in understanding 'matter asymmetry of the universe, or why the universe is primarily composed of matter, rather than antimatter.' The results are published in the Physical Review Letters."

Philom writes "Numerous scientific studies have demonstrated that electronic voting machines can be reprogrammed to steal votes, so when researchers Alex Halderman and Ari Feldman got their hands on a machine called the Sequoia AVC Edge, they decided to do something different: they reprogrammed it to run Pac-Man. As states move away from insecure electronic voting, there's a risk that discarded machines will clog our landfills. Fortunately, these results show that voting machines can be recycled to provide countless hours of entertainment."

An anonymous reader writes "India, the world's largest democracy, votes entirely on government-made electronic voting machines that authorities claim are 'tamperproof,' 'infallible,' and 'perfect,' but last week security researchers proved that they can be manipulated to steal elections. A team led by Hari Prasad, Professor J. Alex Halderman, and Rop Gonggrijp released an awesome video that shows off hardware hacks they built. These machines are much simpler than e-voting designs used in the US, but as the research paper explains, this makes attacking the hardware even easier. Halderman's students at the University of Michigan took only about a week to build a replacement display board that lies about the vote totals, and the team also built a pocket-sized device that clips onto the memory chips, with the machine powered on, and rewrites the votes. Clippy says, 'It looks like you're trying to rig an election ...'"

ogre7299 recommends an announcement out of Caltech on a milestone for HIFI, the Herschel Space Observatory's Heterodyne Instrument for the Far Infrared. "The Herschel Space Observatory has revealed the chemical fingerprints of potential life-enabling organic molecules in the Orion Nebula, a nearby stellar nursery in our Milky Way galaxy. ... This detailed-spectrum, obtained with the Heterodyne Instrument for the Far Infrared (HIFI) — one of Herschel's three innovative instruments — demonstrates the gold mine of information that Herschel-HIFI will provide on how organic molecules form in space. The spectrum, one of the first to be obtained with HIFI since it returned to full health in January 2010 following technical difficulties, clearly demonstrates that the instrument is working well. ... [The HIFI instrument had previously been offline since] August 2009 when HIFI experienced an unexpected voltage spike in the electronic system, probably caused by a high-energy cosmic particle, resulting in the instrument shutting down. On 14 January 2010, HIFI was successfully switched back on using its spare electronics, with science observations commencing on 28 February."

alphadogg writes "Three University of Michigan computer scientists say they have found a way to exploit a weakness in RSA security technology used to protect everything from media players to smartphones and e-commerce servers. RSA authentication is susceptible, they say, to changes in the voltage supply to a private key holder. While guessing the 1,000-plus digits of binary code in a private key would take unfathomable hours, the researchers say that by varying electric current to a secured computer using an inexpensive purpose-built device they were able to stress out the computer and figure out the 1,024-bit private key in about 100 hours – all without leaving a trace. The researchers in their paper outline how they made the attack (PDF) on a SPARC system running Linux."

An anonymous reader writes "University of Michigan researchers have crammed an ARM Cortex microcontroller, a thin-film battery, and a solar cell into a package that is only 9 cubic millimeters in volume. The system is able to run perpetually by periodically recharging the on-board battery with a solar cell (neglecting physical wear-out of the system)."

no-life-guy writes "Researchers at the University of Michigan have developed a web-game to harness the natural human abilities for electronic design automation (EDA). Arguing that people are still much better than computers in games of strategy and visualization, and that we'll do anything as long as it's fun, a group created FunSAT — a game where an average Joe gets to solve a Boolean satisfiability problem. Known as SAT, this problem is an important component in various hardware design tools from formal verification to IC layout to scheduling. The pilot version is a puzzle-like single-player Java app (akin to those addictive web-games), but the researchers envision that it can be extended to a multi-player (and, perhaps, replace WoW as the favorite past-time of the millions), so anybody can be a hardware designer. If anything, this is definitely a great learning tool."

no-life-guy writes "Researchers at the University of Michigan have developed a web-game to harness the natural human abilities for electronic design automation (EDA). Arguing that people are still much better than computers in games of strategy and visualization, and that we'll do anything as long as it's fun, a group created FunSAT — a game where an average Joe gets to solve a Boolean satisfiability problem. Known as SAT, this problem is an important component in various hardware design tools from formal verification to IC layout to scheduling. The pilot version is a puzzle-like single-player Java app (akin to those addictive web-games), but the researchers envision that it can be extended to a multi-player (and, perhaps, replace WoW as the favorite past-time of the millions), so anybody can be a hardware designer. If anything, this is definitely a great learning tool."

hoytak writes "An expert in electoral fraud, professor Walter Melbane, has released a detailed analysis (PDF) of available data in Iran's controversial election (summary here). While he did not find significant indications of fraud, he does note that all the deviations from the predicted model are in Ahmadinejad's favor: 'In general, combining the 2005 and 2009 data conveys the impression that a substantial core of the 2009 results reflected natural political process... [These] stand in contrast to the unusual pattern in which all of the notable discrepancies between the support Ahmadinejad actually received and the support the model predicts are always negative. This pattern needs to be explained before one can have confidence that natural election processes were not supplemented with artificial manipulations.'" In related news, EsonLinji notes reports in the Seattle PI and other sources that the US State Department has asked Twitter to delay system maintenance to prevent cutting off Iranians who have been relying on the service during the post-election crisis. And if you would like to help ease the communication crunch, reader RCulpepper tips a blog post detailing how to set up a proxy server for users with Iranian IP addresses.

hoytak writes "An expert in electoral fraud, professor Walter Melbane, has released a detailed analysis (PDF) of available data in Iran's controversial election (summary here). While he did not find significant indications of fraud, he does note that all the deviations from the predicted model are in Ahmadinejad's favor: 'In general, combining the 2005 and 2009 data conveys the impression that a substantial core of the 2009 results reflected natural political process... [These] stand in contrast to the unusual pattern in which all of the notable discrepancies between the support Ahmadinejad actually received and the support the model predicts are always negative. This pattern needs to be explained before one can have confidence that natural election processes were not supplemented with artificial manipulations.'" In related news, EsonLinji notes reports in the Seattle PI and other sources that the US State Department has asked Twitter to delay system maintenance to prevent cutting off Iranians who have been relying on the service during the post-election crisis. And if you would like to help ease the communication crunch, reader RCulpepper tips a blog post detailing how to set up a proxy server for users with Iranian IP addresses.

david_a_eaves writes "The Chinese government is mandating that all computers sold in China come with Internet blocking software. Rob Cottingham writes an excellent piece noting how the censorship application of this software should be the least of our concerns. This new software may create an opportunity for the Chinese Government to appropriate these computers and use them to create the worlds largest botnet army." Update: 06/11 21:26 GMT by T : J. Alex Halderman writes "My students and I have been examining the Green Dam censorware software. We've found serious vulnerabilities that can be exploited by any web site a user visits with the software installed. We also found that some of the blacklists seems to have been taken from the American-made filtering program CyberSitter. We've posted a report and demo."