UW Computer Security Research and Course Blog

(originally written 11/07/2008)

Early next week, the University of California, Berkeley, in a joint effort with Nokia Research Labs, intends to launch Mobile Millennium, a project that aims to capture traffic patterns accurately and in real-time by harnessing cell phones as mobile sensors.  Previous work has only considered static sensors explicitly placed at location of interest (e.g. major congested roads); as such, their approach suffers from the inherent existence of blind spots in their analyses.  On the other hand, the design of Mobile Millennium lends itself well to monitoring traffic patterns anywhere participating mobile phones receive signal.

In Mobile Millennium, users will be able to voluntarily download a free Java program onto their mobile devices, which monitors their location, speed and direction of movement.  This information will be collected into a large database and analyzed collectively to determine the presence of traffic jams and stranded vehicles, for example.  This technology currently targets GPS-enabled phones whose service provider is a GSM network, e.g. AT&T or T-Mobile.  Mobile Millennium has set virtual trip lines at certain geographic locations so that whenever a participating device passes through the trip line, information is relayed to the project servers. This project will focus on traffic on major roads between the Bay Area and Sacramento, but intends to expand to arterial roads in the future.

From a security perspective, the project incorporates “Privacy by Design” principles so that no data point can be directly connected with a particular phone.  To achieve this involves stripping incoming data of identifying information in addition to encrypting transmitted data and analyzing data on a need-to-know basis.  To further alleviate security fears, Mobile Millennium operates on a completely voluntary-basis and users can stop participating at any time.

Stakeholders
Despite the claims of system anonymity by the creators of Mobile Millennium, users are risking knowledge of their location and identifying information when they volunteer to participate.  Even in the case that the the project adheres to the aforementioned principles of Privacy by Design, there are certain cases in which one can infer user identity from location and external knowledge.  For example, if a participant habitually travels to an area devoid of other participants, then this individual’s movement can be monitored without the system explicitly mapping her data point to her person.  If this area happens to be her home address, then even more information is compromised.

From a more optimistic perspective, by design, Mobile Millennium can track whether participants are stranded on roads; one could easily imagine how this knowledge might facilitate increased precision and a more speedy response to emergency situations, stranded vehicles, etc.  (Thus, perhaps towing companies may be an indirect stakeholder as well.)

In addition,the participating device may witness a significant computational overhead, as it is constantly streaming data to Mobile Millennium servers.  If the technology becomes more main-stream, will this affect how cell phones are created?  Will this have an impact on the types of encryption that can be done, now that computing power is even more limited?

Because users are encouraged to have unlimited plans, the creators of Mobile Millennium themselves may be an indirect stakeholder; if this limitation prevents a certain demographic or region from participating, Mobile Millennium may end up studying traffic patterns of a limited subset of the population and draw biased conclusions.

In addition, citizens of the targeted region are direct stakeholders, even if they are not participants.  Supposedly anyone can check the status of traffic on Mobile Millennium’s website; this technology is intended to relieve areas of major congestion directly, or at least provide the means for the state Department of Transportation to improve infrastructure.  (Thus, one might consider the Department of Transportation another indirect stakeholder.)

Finally, the police department has a potential and indirect interest in the development of Mobile Millennium.  The lack of individual privacy in the project implementation (as well as the perception of such) may effect crime on the road.  This is further discussed in the “Adversaries” section.

Assets and Security Goals
As discussed above, the general privacy of participants should be a major concern of Mobile Millennium.  While the creators have certainly gone to some length to protect the identities of their users, it is not clear that such measures are enough to maintain true anonymity.

In addition, personal security may potentially be at stake; a user might not feel comfortable if strangers know that he is stranded on an isolated road in the middle of the night.  He might very well prefer to call a friend for help rather than alert Mobile Millennium of his distress.

Potential Adversaries and Threats
Though typically not portrayed as an adversary, the police have strong (and arguably, semi-justified)  motivation to infringe on user privacy rights. For example, if one can identify people via Mobile Millennium, it would be easier to find the aggressor of a hit-and-run incident.  It might be easier to track the whereabouts of or verify alibis of suspects.  Similarly, the federal government has an interest in breaking any privacy-ensuring mechanisms set in place by Mobile Millennium; such a breach would facilitate any tapping and/or tracking of individuals of interest.

The government may also have an interest (albeit, a different one) on the state and/or judicial level.  If they can even determine that a certain demographic frequents certain roads in certain patterns, this may induce a bias toward one class (e.g. a wealthier class) over another to increase revenue.

Potential Weaknesses
From a security perspective, there seems to be no way for a user who decides to stop participating to ensure that indeed their information is no longer being tracked by Mobile Millennium.  In addition, who is in control of the system?  If the control of the system gets into the wrong hands, are there mechanisms in place to ensure that an adversary can still do no harm despite having access to the centralized information?

Potential Defenses
To the weaknesses above, defenses might include mechanisms to ensure that a former participant is indeed no longer participating.  An extreme version of such a defense would be to get a new phone, but this is cumbersome; it should not be at the expense of the user to ensure his or her non-participation.  The claimed ability to be able to disable participation at any time is already a first line of defense against privacy issues and/or qualms had by the user.

Evaluation and Conclusion
Mobile Millennium proposes a new technology that allows the tracking of large group of people without explicitly identifying them.  However, with this technology comes a lot of privacy issues; in particular, it is questionable how much identifying information could be inferred without explicit mapping of data point to name.  Because there will always be conceivably special cases in which little information is needed to deduce a person’s association with a data point, it is extremely difficult to defend against this kind of privacy breach without refusing to participate in the first place.  One can think of addressing this potentially contrived case as a “worst case analysis”.  Any theoretical defense toward adding data points to make an inferred data point more anonymous debunks the very purpose of this study, which involves understanding the traffic patterns of real people.  While it seems that technology of this type poses severe privacy issues, it will inevitably become more mainstream because of the benefits that a system gains from tracking people (or things) within it.  In fact, a similar technology is already implemented in many hospitals as a way of tracking equipment, patients and staff.  (It should be noted, however, that this technology is restricted to the domain of the hospital and would not, for example, aid the police in tracking their suspects.)  Toward that end, it is increasingly necessary to resolve these issues in a way that renders the technology simultaneously respectful of individual privacy and contributing to society as a whole.

iGoogle is a personal web portal service of Google, which serves as a customizable start page to the Internet.  It was Google’s star product in 2007, whose traffic had increased by 267.64%.  In iGoogle, users can have several pages under different named tabs.  Users can add Google gadgets and RSS feeds to the pages.  Page layouts can be customized.  iGoogle is an open platform that anyone can create their own gadgets. Users can also share their iGoogle pages with others by sending out their pages with or without the settings for the contained gadgets.  Different from most other web portals, iGoogle dedicates large amount of space on top of its pages to Google’s own web search service.

There are many stakeholders of iGoogle.  Users are the most obvious and probably the most important direct stakeholders.  Google itself is a direct stakeholder as well.  It benefits not only because it can collect all kinds of information about its users, but also because users will be more likely to use its web search service — Google puts a big search box on the top. Creators of the Google gadgets are also direct stakeholders because they use iGoogle as the platform for their web applications. There are two kinds of indirect stakeholders. Those content (RSS) providers, such as New York Times, are indirect stakeholders because their RSS feeds can be directly added to iGoogle.  Advertisers are the other indirect stakeholders because iGoogle promotes Google’s web search service as mentioned.

One important asset of iGoogle is its handiness.  iGoogle has tons of useful and high quality gadgets for various scenarios and purposes. Users can put as much information as possible through it.  It also loads very fast which is important because most users use iGoogle quite frequently.  Actually, a great amount of users set iGoogle as their browser homepages.  Had iGoogle taken tens of seconds to load, it wouldn’t have been that popular.

Another asset of iGoogle is the users’ personal information. iGoogle gadgets, such as, weather, Gmail, calendar, to-do list and sticky notes, each contains very private information about users.  Being a collection of these gadgets, iGoogle is more privacy-sensitive than any single one of its gadgets.  Thus, keeping the private information safe is a very important security goal of iGoogle.

Towards these assets, there are several threats.  One is looking-over-shoulder attack.  It could be friends, or strangers, or hidden cameras, depending on where iGoogle is used.  It is a threat because by looking at one’s iGoogle pages from behind, the attackers can know a lot about the user, such as his or her interests, stocks and agenda of the day.  Another similar but more serious threat occurs when other people use your browser.  As many users set iGoogle as their browser homepages and never log out for convenience, no password is needed in order to open iGoogle on their browsers.  In such case, people who gain access to your browser will also gain access to all your private information on your iGoogle.

Another threat is eavesdropping on the network.  This is always a threat for network applications, but it is more serious for iGoogle as it does not encrypt the communication between client and server, and gadgets are responsible for their own communication with the corresponding services.

Since iGoogle is an open platform, one threat is the malicious gadgets.  As reported by media, users easily trust the gadgets found on Google’s gadget directory.  They don’t realize that these gadgets can be developed by anyone not just Google.  Also, since the malicious gadgets might be used along with other important gadgets like Gmail on the same page, they might be able to gain some access to these gadgets through some bugs in iGoogle or the browsers.  More easily, the malicious gadgets can just slow down the loading speed of the whole page, which directly harms the handiness asset of iGoogle.

I think iGoogle is weak against many of the above threats.  One is that, iGoogle uses “http” instead of “https”, which obviously could reveal what apps users are using to the eavesdroppers.  Also iGoogle does not show if the gadgets themselves are using secure connections or not.  For example, when using Gmail alone, one can notice that it uses https and there are other indications such as a lock in the status bar.  However, in the case of iGoogle, one cannot tell if the Gmail gadget is using “https” or “http”.  Users may thus make some wrong decision, for example, reading emails through a public WIFI.

Another potential weakness against eavesdropping is that the iGoogle pages appear highly frequently on the network, especially when being set as browser homepages.  This could definitely ease eavesdropping, as there is more redundancy.  I am not sure how much such redundancy will help the attackers, but the attackers do get more information about the encryption. Also when setting iGoogle as browser homepages, and seeing it over and over, users may lower their alertness against privacy leak as iGoogle becomes more a usual thing to them.

The “share” feature of iGoogle is another weakness against privacy leak, because it also enables users sending settings for gadgets along with the page to other users.  One case is that users might misunderstand the settings for gadgets as preferences for applications and send them.  They will be surprised that their sensitive information such as the contents in their sticky notes, and their calendars are also sent out.  Generally, what are sent depends on the implementation of each gadget.  The other case is that people who have gained access to one’s browser can send out his or her sensitive information by just a few clicks.

There are many possible defenses against the above-mentioned potential attacks.  One defense against the weakness of the “share” feature is asking for authentication (password) before sending out the settings for gadgets instead of just giving out warnings as in the current iGoogle.  The result is that malicious people can no longer send out all the private information easily.

Another defense against looking-over-shoulder attack is to hide iGoogle pages when users are accessing iGoogle using an unrecognized IP address.  This can prevent occasional privacy leak when getting online using WIFI in a public area.  Some browser extensions can also be helpful by using more complex detection mechanisms.

As for secure connection, iGoogle could also let users to decide whether or not to use “https”, as Google has done in Gmail.  Since “https” may slow down the page, it is possible in some cases that users prefer faster loading.

iGoogle could also provide some indication on whether or not the gadgets are using secure connections.  For example, putting a lock icon on the gadget’s title bar to indicate that the gadget is using secure connection.  Such indication is important in helping users make the right decision.

As iGoogle keeps growing, the security issues mentioned can become more and more important.  If not taken seriously, users’ privacy can be easily revealed to malicious people or organizations.  As web browsing becomes more and more important in our daily life, iGoogle will be much more valuable.  It can grow into a platform for all kinds of web applications, and a personalized mash-up center, and a true start page to the Internet.  And when more and more private information are placed through iGoogle, Google must provide better and complete mechanisms for protecting users’ privacy in all contexts.

The security issues mentioned above are not alone with iGoogle, but also with all other web portal services such as Netvibes, My Yahoo, and Windows Live.  Currently, developers have been focused on creating more useful and prettier gadgets in order to attract users.  Less work has been done to improve the security of the platform.  Users also haven’t yet paid attention to these issues, even though they are aware of these issues when using similar services separately, for example, Gmail.  The success of iGoogle not only shows the potential of web portals but also emphasizes these security issues.  If there is something goes wrong, even if it is the fault of a third party gadget, Google will definitely be blamed.  I like iGoogle a lot. It is fast, open, and has a lot of gadgets. I hope to see more security concerns from Google, as I already have tons of private information there.

When in a rush and craving a quick soda or snack, people just don’t want to deal with the hassle of lines and other people. That is why the vending machine is such a great invention; it’s a fast, easy way to get something so people can continue on their way. But there’s a way to make this process even quicker and simpler. Everyone has a cell phone nowadays. Why not purchase the items via mobile phone? In Japan, they already have such a device; they’re called wallet phones. Wallet phones combine an I-mode phone and the FeliCa smart card. To use it, one doesn’t even have to press any buttons. When the vending machine is ready, the user place their cell phone near it, and the cell phone beeps to let the user know the transaction is complete. But this wallet phone doesn’t only work with vending machines, it also can serve as a bus or train pass if the right equipment is set up. To counter fraud, the FeliCa smart card dynamically generates an encryption key each time mutual authentication is performed. Though not the default, the wallet phone can be configured so that a four digit PIN is required before any transaction. The phone operates much like a debit card with a limit of about $500. If the phone gets lost or stolen, the user must call up the company and cancel the service.

(Read on …)

Introduction

Today internet is not limited to just desktops and laptops. There has been a flurry of portable devices that can connect to internet and allow for local storage and use of software applications. As users own more than one such web-enabled devices, their data and applications get more and more distributed. Distribution of data also happens when multiple people are collaborating on some work. This need of data sharing and synchronization motivates the existence of a system which lets people manage shared data on various devices and with multiple collaborators.

Technology Overview

Live Mesh by Microsoft allows users to create a network of their web-enabled devices – mobile phones, laptops, desktops etc, and have synchronized data on all of them. It also allows users to do a remote desktop from any device to the other on this mesh and work on it. Basically the idea is that the user should be able to access his data from anywhere in world. Besides this sync-up between devices, users are also provided with a 5GB space on Microsoft’s servers which they can access anytime through internet. With this product, Microsoft is targeting the consumer market right now and has not focused on a business solution. The users are allowed to add other users to their mesh with accessibility controls to the shared folders. The added users can sync up this data on their devices and work on it. The system allows the owner to view any updates about his mesh as “news” items on the mesh bar. People can give comments about the shared data in the news section thus helping in collaboration. The authentication mechanism for the mesh is based on one’s Windows Live passport.

Stakeholders

Individuals are the biggest the stakeholders since all their shared information is at stake. The information might contain secrets about financial or personal life which should not be shared like credit card numbers, passwords, personal letters etc. Besides individuals, a lot of collaborative groups are direct stakeholders. These groups can range from a group of students collaborating on a project to a corporate team sharing company data. Hence in this case, the whole group is the stakeholder.

Assets/ security goals

The main asset is the data that is being shared between the devices, be it for individuals or for organizations. Loss of important financial details can be dangerous for both. On an individual level, illegal access to photographs or documents can reveal personal information like relationships, problems, habits etc. For the organization, confidential data can include collaborative work on certain projects, information about employees etc.

The security goals can be at three different levels – network, device and user. Data privacy depends a lot on the security of the network protocols used in the communication. This goal is mostly achieved because of the already available secure protocols. Given this big mesh of devices, device authentication mechanism is also important. Also, the device should be secure enough to block any attempts by malware or hackers to break the security and access stored data. The same device may also be used by different users in which case we need a good user authentication mechanism. Currently text passwords are used but more secure means can be thought of.

Potential adversaries/threats

A major threat relates to shared data. This may arise from personal attacks against somebody or a business rivalry. Personal attacks can be from people in your social circle who try to hack your password to corrupt your data or just know secrets about you. These people have limited sources but a big organization has access to a larger computing base and can use that to hack into another organization’s confidential data. Microsoft itself could be a potential adversary since it is controlling and has access to all the data transfer and connections between devices. The Mesh software may decide to contact the server regarding the information being passed on between devices to allow study of device interaction for further research. Another potential threat is from malwares. Given that the devices are now connected in a very intimate way, any malware which gets access to one device can possibly spread at an exponential rate through the mesh. Device theft also presents a threat since the device has the latest copy of data from all other devices. The stolen device could be used to keep on syncing the data (I did not find documentation which said that a device can be blacklisted but I guess this feature is already there). Since there is no authentication for the user to use the data locally, this can be a threat to the data privacy

Potential weaknesses

Dependence on a single password – The access to the whole device mesh for a user is controlled by his Windows Live passport. Hence loss of a single password can lead to loss of entire data on all the machines and the attacker may corrupt or destroy all the data. Given increased attacks on text-password schemes, this can be considered a big weakness.

Unencrypted data – The 5GB web space provided to users to maintain online data on Microsoft servers is protected by access control mechanisms but unencrypted. Any breach of these access controls gives the attacker access to this unprotected data of all users.

Potential defenses

Threats and weaknesses arising from a highly concentrated authenticated system can be improved by building a distributed authentication mechanism. Instead of just one Mesh password allowing access to everything, we can use an authentication on separate devices to access data synced from other machines. Having many passwords can present usability issues so the best way will be to have biometrics-based passwords like a fingerprint or retinal scan. But this will depend a lot on accuracy, robustness and feasibility of any such mechanism. To counter device theft problems, immediate blacklisting devices by users can be allowed. The online web space provided to users can be encrypted and fragmented. This will prevent any data leaks due to access control failures. It was discussed earlier that Microsoft itself could be an adversary. To prevent that data should be encrypted in a way that Microsoft does not know what the data is. It just stores and shares.

Risk evaluation

The highest probability threats are device thefts and rapid spread of malwares. The former will lead to access to all synced up data and hence asks for a higher security model. On the existing network of desktops, servers and laptops, there are already innumerable malwares. With the rapid increase in the number of portable web-enabled devices connected to each other, rapid spread is more likely. This will amplify the existing malware problems like spam, denial of service attacks etc. Thus, higher security and monitoring mechanisms are required on the devices. Given the reliance of Windows Live passport on strong cryptographic schemes, hacking the password seems less probable but it may happen by people overlooking on shoulders or use of key-loggers etc. This threat has the highest cost because the entire mesh is dependent on this. Thus the risk presented by authentication mechanism is high and needs to be made more secure. Microsoft itself acting as adversary is less probable given that the current product is oriented to consumers with whom the company is not likely to hold rivalry. Hence this risk is now but it will not be the case if organizations are involved instead of individuals. Lastly, the risk presented by consumers storing unencrypted data behind access controls on servers is not high given that the data is not highly sensitive and good access control mechanisms.

Future and bigger picture

Live Mesh is only the start. With myriads of portable devices coming up which can communicate with each other, the need to share and access data from anywhere will always exist. We can visualize a world where the data is not localized and is floating around on the internet between various servers. The access can be through portable devices like smart phones using biometric feature-based authentication. This model raises some important questions. Is the user comfortable with the idea of his data not being stored locally but maybe on a server thousands of miles away? A user study will probably help establish this. Is the system robust enough to allow for servers failing? This will involve crucial distributed computing issues. Lastly, when the users rely on third parties to store and share data for them, they will want the data to remain private from these parties. The user security model should match with the security model of the system.

Conclusion

Live Mesh is a nice system allowing for connecting all one’s devices together and accessing data on any one of them. While the current version is secure enough for individual consumers, it is still not at the level where big organizations will want to use it because of the high stakes involved. The major limitations are a centralized authentication system based on text password and storage on unencrypted data on servers. We have discussed the ways in which these can be improved. For providing a business solution, a lot of new features will have to be added for more security and collaboration and ensuring that Microsoft has no knowledge about the stored and shared data. In all, Live Mesh is a great step towards a future of unified technology at human disposal.

Bank of America (after its acquisition of MBNA in 2005) started offering “One-Time Credit Card” (OTCC) numbers to all of its credit card holders; the trade name of this service is “ShopSafe.” MBNA had offered this service back in the 1990’s; several other banks had also followed suit. This security review is of the “ShopSafe” system currently used by Bank of America.

To obtain a OTCC, a cardholder must login to BofA’s online banking site, where a Flash applet allows them to review existing OTCCs, or create a new one. Creating a new one prompts the cardholder to specify a spending limit and expiration date (with a minimum of 2 months from the present) for the new OTCC. The number is then created, complete with a 3-digit CVV2 code. The cardholder can use this OTCC in any context where a regular credit card number would do: buying things over the internet, via phone, mail-order, etc. Since the OTCC can have a low limit (typically just over the amount of the intended transaction), even if the credit card number is compromised (e.g. when an online merchant’s database is hacked), the amount of damage is limited. If the attack occurs too late, the OTCC may have expired and so is not a security risk. Most importantly, the OTCC cannot be easily linked back to the cardholder’s “real” credit card number, with its higher spending limit and longer expiration date.

Stakeholders
The cardholder is the primary stakeholder; it is her money and credit reputation that stands to suffer from any theft of credit card information. The financial institution offering the credit card (in this study, Bank of America) also has a direct interest in reducing the frequency and magnitude of credit card fraud, as most card issuers will simply take the money lost to credit card fraud as a write-off: the cardholder is typically not responsible for anything if the fraud is reported in a timely manner.

Assets
The cardholder’s “real” credit card number is the primary asset. With its high limit and long expiration date, it is a valuable target. A compromised card is also something of a pain to replace, requiring that the cardholder call the issuer and have a new card shipped via mail. Another asset is the cardholder’s credit rating – damage to this rating due to identity theft can be very expensive and time consuming to revert.

Adversaries
There are many criminals who are interested in people’s credit card information, both to perform identity theft and to simply steal money. Credit card numbers can also function as a relatively strong identifier for tracking purposes; a cardholder may be concerned about advertising agencies or unscrupulous retailers gathering too much information about him because they can link all his purchases together via their common credit card information.

Potential Weaknesses
The BofA OTCC system does not produce a full 16-digits worth of entropy with each new OTCC number. The most-significant 4 digits are always the same (as is usually the case across all credit cards issued by a given financial institution); more worryingly, the 5th through 8th significant digits are also always the same for each OTCC number (in the author’s few months of experience with the system). Thus, a OTCC has no more than 9 digits of entropy, when it could have 1000x more. Moreover, the 5th-8th digits of a OTCC are different from the corresponding digits of the “real” credit card number. Thus, it should be possible for a thief to distinguish OTCC numbers from real ones – if a thief has multiple credit card numbers from what they believe to be the same person, they can perform this simple check to see if they have only OTCCs, and to distinguish the “real” credit card number from the others. A thief can then execute different attacks based on the kind of card number they have: stealing smaller amounts of money more immediately for a OTCC, and saving larger attacks for “real” cards when they are more likely to work.

Another potential weakness of the system is that, presently, the shortest expiration date that can be set is two month’s from the current month. This leaves a “window of vulnerability” open that is much longer than need be; if these credit cards are truly used in a one-time fashion, it would be ideal to set an expiration date to a week or so. Even though a credit card’s expiration date is typically expressed only as a month and year, BofA could maintain, internally, a more precise expiration date and thereby decrease the window of vulnerability substantially.

Potential Defenses
The BofA OTCC numbers likely display less entropy than they could to make it easier for the bank to do the extra lookup necessary to resolve a OTCC number to its owner’s account. Providing more entropy would require more processing on the bank’s part, which is apparently not cost-effective for the extra security it would provide.

Similarly, providing expiration dates at a finer granularity would also increase security by a small amount, but would entail more complexity in BofA’s credit card processing. It is likely for legacy reasons that the system has been implemented the way it has been.

Risks
The benefits of using OTCCs regularly clearly outweigh the presence of these potential weaknesses in the system. Even though a compromised OTCC is subject to some attacks, the fact that it likely has a lower limit (most of which has been used up already for the intended purchase) and a tighter expiration date mean that it is much less valuable to any thief. If the thief can discern that he has stolen a OTCC, he may simply not bother trying to exploit it as the potential gains are not very large, which achieves the security goals just as well as if the thief had never stolen the card in the first place.

Conclusions
The BofA OTCC system seems quite secure. A OTCC offers similar benefits to a one-time pad. Since card numbers are not reused, or reusable, their value to an attacker is much lower than that of a real credit card number which is of enduring value. OTCC also provide “strong unlinkability” between transactions made by the same person (at least as far as 3rd parties go), which protects the privacy of the purchaser. There is little that discourages the use of OTCCs. I only hope that someday we will have a physical analog – a physical credit card that, maybe because it uses RFID technology and not a hard-to-modify mag strip, can change numbers after each transaction, or at the end of each day or so. This would make credit card fraud much more difficult, and seems implementable within the next few years.

Summary:

This security review is about a technology named Skinware (I learned about this at Grace Hopper; web searches were unable to uncover any real literature – I think it has been sold and, most likely, renamed). Skinware was developed at HP Labs as an alternative drug delivery mechanism.

The basic idea behind Skinware is to facilitate reliable and accurate medication using a programmable chip, some teensy micro-needles, thermal plastic, and some glue that attaches Skinware to you. As a patent, I would wear the Skinware patch (it’s about 1/8” thick) on my body – usually somewhere on my chest, between the shoulder and collarbone. There is a teensy programmable chip in the center of the patch, and this chip controls wires that heat up thermal plastic that is located below reservoirs that contain medications. As the plastic heats up, it expands and pushes the medicine out of the reservoir and into some micro-needles that deliver the meds into your epidermis (the plastic won’t shrink upon cooling). These micro-needles are so small they don’t even go deep enough into your skin to hit any nerves, so this should be a pain-free device.

Skinware is designed to address issues of people who forget (or skip) doses, unintentionally take the wrong dose, or who mix different medications. The chip can be set to release meds in smaller, more continuous doses throughout the day, and can be set to release multiple medications (from different reservoirs) at various times to avoid negative interactions. By being pain-free, people who don’t like needles would presumably not have the same problems with Skinware medications as they may have otherwise. The talk I heard even suggested using bio-feedback approach to medicine delivery, in which a monitoring device would be planted somewhere on your body (e.g. to measure blood sugar in diabetics) and when needed could communicate with the Skinware via bluetooth to instruct it to deliver medications.

Stakeholders:

Since this is a technology designed to make it more likely, easier, and less painful for patients to medicate themselves, an obvious stakeholder in Skinware is the patents themselves.

Other stakeholders include doctors and pharmacies; the idealized method of use for Skinware was that the doctor writes a prescription, which the patient takes to the pharmacy where the Skinware is programmed and the reservoirs are filled. Obviously, having the training for pharmacists and the technology to work with Skinware is crucial under this plan.

Stakeholders for Skinware also include HP Labs (or whatever medical devices company the technology was sold to), since there is intellectual property that they would like to protect and a profit to be made in medical devices. Indirect stakeholders also include the manufacturers of drugs, software, and hardware technology used in Skinware.

Assets and goals:

The drug itself is an asset, and protecting it is a goal, as with most medicines that require a prescription. In this context, protecting it means writing un-hackable software to ensure that the drugs are delivered as the doctor intended.

Another asset is patient privacy, and how to prevent eavesdropping (assuming the existence of biofeedback via bluetooth) is a goal. This could inform other people within range what types of medication the patent is taking, which could have negative consequences for the patient (depending on the medication), or even cause a threat in the sense that people may want to steal the patent’s Skinware for any drugs remaining inside.

Adversaries and threats:

On adversary is drug dealers/abusers. Assume a drug dealer has a way of obtaining Skinware presumably via some nefarious deed full of some desirable drug. Their goal would be to hack the Skinware to (maybe) deliver all of a particular drug at a single time – delivering a tremendous high, or causing overdose.

Another (not really) adversary would be the novice pharmacist, who could unintentionally misprogram someone’s Skinware. The threat here is that a well-meaning pharmacy worker writes buggy code, and a law-abiding patient ends up with the wrong medications at the wrong times, or in wrong doses.

Weaknesses:

One of the first weaknesses I can think of is its use of heat to release the drugs. Depending on how the technology works, I could imagine applying a hot iron to the back side of your Skinware to force it to release drugs at a particular time.

Another weakness has to do with using biofeedback and bluetooth devices to communicate with the Skinware. Imagine multiple patients with Skinware all in the same room,
where all Skinware is listening to a single patient’s biofeedback. This would be problematic if the biofeedback instructs “Release more of medication A,” and other patents, who may or may not have medication A loaded (or is installed :-P) into their Skinware, end up with a software crash, or if the Skinware guesses and releases medication A’ as a substitute when it isn’t needed.

Defenses:

One thing that could be done to defend against certain types of drug abuse or improper drug interaction would be to have explicit hardware switches that prevent drug release of all the drugs at a single time, or of two particular drugs in unison. If this is possible, then it would prevent the first weakness listed above.

A defense against the bluetooth confusion that involves crossed signals would be to enforce a system that requires authentication before acting on a particular message from a biofeedback device, and using encryption to ensure that eavesdroppers do not have access to the messages being sent.
Risks:

There are several risks that I forsee for this technology, including unintended drug overdoses or drug interactions due to incorrectly programmed or malfunctioning devices. In the unfortunate circumstance that someone does have a bad interaction or overdose, it might be much harder to diagnose what went wrong; in the case of physical pills or injections, the patient or patient’s caregivers can usually tell if too
many pills were taken or if an injection was administered improperly. One reason to use Skinware is that it is supposed to be easy and painless. However, by taking control away from the patient and requiring trust in the pharmacist, the patient is now at risk of mistakes made by the pharmacist, and the pharmacist is at risk of increased liability. In addition, patients may forget to change their Skinware on the appropriate schedule or accidentally wear multiple Skinware patches at one time. Of these problems, the former (forgetting) seems more likely to occur among busy people, while the latter (multi-patch mistakes) seems more likely to occur among the elderly. Both of these problems are also present using pills, but the ease of use may make it easier to forget, since people won’t be thinking about it, and the elderly may have
difficulty understanding how the patches work.

As mentioned earlier in this review, there are privacy risks and “hack-ability” issues associated with communicating via bluetooth, but those issues could be resolved before that component of this product hits the market; if it ever does.

As far as drug abuse issues are concerned, I think that it is unlikely that Skinware will become an attractive target for abuse. While it may not be totally resistant to attacks, it is likely more difficult to obtain Skinware patches, and even if they are obtained, there may not be enough medication inside to make the payoff worth the effort.

Conclusions:

Skinware is designed to improve health care by providing easy to use, pain-free medication delivery in a manner that can be much healthier for the patient. Not only can Skinware accommodate timed releases and smaller, more frequent doses, but it can time these doses in a way that prevents drug mixing and that does not inconvenience the patient.

Alternatively, most risks involved with using Skinware seem somewhat minor. Although pharmacies and doctors will require more training, and patients could be likely to forget or otherwise unintentionally misuse their Skinware, this can happen just as easily with current medications. The drug abuse risk here seems very low or minor when compared to pills or injections (although I’m not at all informed about these things).

The one caveat I have regarding Skinware is the use of bluetooth technology to provide biofeedback or other information about when and how to release medication. Before this component of the technology is released, much care should be taken to ensure the privacy and safety of the patient at all times. Ultimately, I conclude that the benefits of Skinware outweigh the risks, and it would be interesting to see this technology hit the markets and succeed.

In September of 2008, a 24-year-old woman in Maharashtra, India, was found guilty of murdering her fiancé. Her trial set a (troubling) legal precedent because brain electrical oscillation signature (BEOS) testing was cited as major evidence in her conviction. This controversial method involves placing electrodes on the head of the accused and analyzing visual recognition signals to prove whether or not someone has prior recollection of a crime.

(Read on …)