UIUC security researchers apparently feel that no amount of work on existing browser will be sufficient so have set out to design a new one with security built-in from the start. The browser, OP, first and foremost breaks down into a core set of modules and security policies governing the interactions between them. This seems like a good idea in terms of compartmentalizing risk when vulnerabilities eventually crop up. They also seem to agree largely with Firefox’s approach to adding features intending to enhance security for 3rd party plugins as well without demanding more of those developers. I especially like their approach to transparency, where apparently there will be some capability to backtrack security problems and identify from what site they originate.

I wish this research team had more strongly considered working with an existing open source browser, Firefox in particular. They are using KHTML for OP and apparently plan multiplatform support using WebKit but while they may get ahead on security, how much are they sacrificing on other fronts to do so?

Given the recommendations to use a second, different, more secure browser I saw some time back for accessing sensitive sites, I think OP will have a place in my toolkit, regardless, as it seems to be a great fit just for that.

EE Times has an interesting story about a 10USD single chip platform for building wireless medical devices. This immediately made me thinking about the research around hacking of implantable medical devices. The Vena platform is not intended for implants so the potential cost of an attack is lower but not by much.

Of the two standards mentioned in the article, IEEE 11073 appears to be solely a data exchange and transport specification and only the Bluetooth Medical Device Profile seems to speak to security. However, I could not find much substantial information on what that means. Would this be the standard security built into Bluetooth itself or something more? Would the security components, beyond device pairing, be optional or required? These are important questions when the story spends so much time explaining how Vena will make it easy to fling confidential and sensitive medical information around on otherwise imminently sniffable RF.

Worse, the Vena platform provides other connectivity mechanisms with which an implementer may choose to provide naive, non-secure options. The fact that it is capable of a full TCP/IP stack says to me that we could easily see standard wired connectivity with data exchange entirely in the clear. Such a commodity chip is unlikely to have the horse power to use standard encryption like SSL and unless Cambridge Consultants is provided hardware support for appropriate data protection, I am skeptical OEMs will add anything in their software and firmware implementations.

I’d love to see better adoption of technology in the medical field, to improve patience care and reduce cost. The potential for technology to help here is enormous especially given how resistant the field has been to date. But to see initiatives that don’t focus on patient confidentiality and the appropriate security worries me more than any potential advantage we could gain.

I talked about Chris Soghoian’s analysis of Facebook’s newly upgrade privacy controls in the last news cast. The net-net is that the changes really don’t enhance privacy in any meaningful way.

I just saw an AP story on The Globe and Mail of a provable security hole that allows perusing of private photos. This is a compelling breach as the expert who found it, Ng, and the AP reporter were pretty much able to view private photos at will. Facebook responded promptly to the report of the issue and claims to have fixed the defect within an hour of the notification.

It is easy to urge caution against sharing personal information. With photos, this is easy advice to follow as the benefit of sharing is largely social so the sacrifice is not too great. Unfortunately the problem isn’t restricted to just photos. Any personal info you share with an online service could be caught out by an inadvertent defect or an intentional attack. And much of that information is the price of admission to fairly valuable services like online banking and other professional services.

I linked to a piece by Bruce Schneier on how TOR’s encryption does not make it a security tool. This cannot be stated strongly enough. The simple fact is that at the exit node from TOR, all your traffic is returned to whatever it was on entry. If you use clear text HTTP, then that is what also exits the network, regardless of how it is handled within the network, by the nodes.

Hackzine has an article that emphasize many of these points. It makes some additional points about the kind of scrutiny to which TOR traffic is provably subjected.

Anonymity is not the same as security. Be careful when using and advocating TOR as just one tool, among many, to help privacy online that you do not make this fundamental mistake and over sell it. Even strong security does not absolve you from not exercising a dash of skepticism and care. And consider how high profile TOR is, there is no surprise that many are watching it closely and that I have linked and spoken about many exploits that have been run against TOR to erode even its limited anonymizing capabilities.

Ars has the explanation. Apologies for linking to this rumor in the last set of quick links. According to Ars, incomplete information and assumptions about Microsoft’s Rootkit Reveal actually led to what would seem like a reasonable conclusion, especially given Sony’s involvement and past antics. Glad to see and share a clarification on what would otherwise be a rather inflammatory story.

Technorati Tags: DRM, malware

Bruce continues to ask the hard questions this time much more specifically about the TSA’s screen practices and criteria. Three more parts to go, if you aren’t subscribed to Bruce’s feed, including the no-fly list up next.

This is the first part of a planned five part series. Bruce asks the questions we all want to ask of the TSA head, Kip Hawley. More importantly, he got permission to share Kip’s answers. I don’t think there is anything too surprising here. Would you expect the TSA to own up to performing arbitrary procedures that don’t have some sort of rational expectation?

I think the discomfort I still feel in the face of these insights is the discrepancy between the described theory and testing and what actually happens on a typical day, at a typical checkpoint.

Also, why should it take someone like Bruce to get this information? Many have been equally critical of the TSA’s practices and their lack of transparency. Hell, as part of our governing institutions, shouldn’t they have an obligation to be more responsive to the average citizen, issues of security not withstanding? The swipes at bloggers as a community reveal much about Kip’s current stance on legitimate questions and information requests. Would he be more responsive to traditional media? Why should it matter?

I’m with Bruce Schneier on this one, speechless. And if you look in the related videos, there are more. Too funny.

I hadn’t really paid this incident much mind, TSA harassment and their subsequent tight lippedness is almost getting to be a non-event. Admittedly, their posting of the surveillance video quickly after the fact is somewhat novel. Having watched it, I still tend to think the truth lies somewhere in between. Characterizing her actions as defiance seem a bit strong, to me. Intentional, sure, but it looks more like an absent minded pour and shake then some rebellious gesture.

Regardless, Bruce Schneier has a write up that finally caught my attention. He lines both sides up in parallel so you can more clearly draw your own conclusion. What I really liked was his quick observations on the psychology more broadly at play here. Regardless of the question of indignity or defiance, this unambiguously points out the need for transparency and accountability to be restored.

I enjoy reading such thought provoking pieces. It is not like there is a lot of controversy or even ambiguity in his discussion of cyberwarfare but it is a strong contrast to the picture many others paint. I like having more rational pieces in my memory to be able to cite or at which to point when encountering the misinformed or poorly educated.

As any good discussion does, he clearly defines his terms, up front. He even breaks them down a point, simplifying things by pointing out that all the addition of the prefix cyber- does is connote the domain. Hence it is not surprising that he mostly contends that warfare, terrorism and even vandalism online have more in common between the online and offline variations. This point resonates well with the one I was trying to make about overblown cybercrime laws when I discussed the recent German lawmaking in the last podcast.

The most he concedes about the difference between cyberwar and traditional is that the difference is more like the introduction of air power and satellites. They did not fundamentally change the nature of warfare, though they had a significant effect. He also uses that notion later in the piece as a warning, that while he is urging greater rationalism, nations should not completely dismiss the effect of the internet on attack and defense.

He spends some time elaborating more on similarities and differences, for example that like attacking physical infrastructure, most cyberattacks are more valuable if they coopt rather than destroy enemy assets. There are some interesting differences in the question of origins and balance. The former in that it can be next to impossible to correctly identify the real attacker and that many attacks will actually capitalize on this difference. The latter is a chilling what if where an under developed nation may make a very different decision about an undiscriminating attack, like a worm, if they feel they have less to lose in the balance.

I encourage you to read the piece for yourself as they is a lot more to it than my simple summary. Whatever your past experience in reading about cyberattacks, I’m pretty sure you’ll find a choice nugget you may not have fully considered or perhaps an angle on an existing fact you may not have encountered. Regardless, I think this is a good cornerstone piece to which we should be referring, among hopefully others, when trying to discuss and prepare in a rational and meaningful way.

Professor Felten has a reasonable write up. Cory’s class blog was one of those sites receiving a demand letter. I thought AACS was so technically superior that the licensing authority could cope by issuing key revocations? Perhaps I have misunderstood the material I’ve read on the subject and the 128-bit integer in question is not one of the many keys in the system that can be revoked. Or if it is, maybe it just isn’t practical to do so. I rather suspect that latter.

It has been several months since this particular cat escape the proverbial bag. This seems like a belated reaction, as ill advised as it is. I think Professor Felten is right, though, that once they started, they couldn’t very well stop without looking foolish. More foolish. I also hope that he is right and that this key reaches the same status as deCSS and moots the current generation of video DRM.

I was glad to see Felten also mention what I think is the greatest real barrier, currently, to widespread sharing of high definition video online. The god awful size. Since I suspect most commercial pirates are interested in selling physical media, that particular hurdle would seem to me to be only effective for personal sharing. Like DRM advocates get any of this and if they do, it just reinforces my view that DRM is about suppressing innovation, not preventing any real threat of piracy.

Technorati Tags: AACS, DRM

Oh, you’ve got to be kidding me. About the only upside to this story is that changing names changes the required privileges, it does nothing in terms of actually granting escalated privileges. Still, it seems like an intensely naive assumption, even with negligible actual security impact.

The article mentions that savvy malware authors will simply rename their installers to bypass the check, though this means foregoing administrative privileges. I worry that with the callous most Windows’ users develop when it comes to the privilege nagging, that a sly author will actually work the situation the other way.

Imagine a benign looking program that presents itself as an installer, updater or uninstaller but contains a vicious trojan. The naive user clicks OK to suppress the incessant system nags and in so doing lets a bit of malware get explicit elevated privileges, not through an exploit but by gaming a silly tact for flagging what needs which rights. Not really very far fetched and may already be happening.

Technorati Tags: malware

I suppose you have to give some credit to Secustick for trying a different tactic. The informed know that encryption is not a panacea. Since a thumb drive is easily lost or lifted, creative thinking about how to secure them should be praised. Well, if done well.

Tweakers.net has a good review of the product. The first thing revealed is that the security feature depends on a Windows only executable. No joy for those who use thumb drives with a mix of systems.

The next big surprise there is no real physical security to the product. The reviewers were able to easily open the case and mode the hardware without losing access to the information on it. This allowed them to thoroughly investigate the software as it ran, revealing a few more scary surprises.

The big one was that they could de-couple the verification of the user’s password from granting access to the flash chips. Only a little less surprising is that the drive doesn’t use any sort of encryption, meaning all you have to do is circumvention the password once, which with the ease of blue wiring the board means this product should never have been certified for the uses the article indicates.

There are more details in the article that would be useful for assessing other products, even if this one doesn’t really live up to any reasonable claim of security.

There sure are a lot of if’s in this article. I don’t propose to have the solution to phishing, but SSL certificate issuance was original supposed to imply verification of identity and we’ve seen how well that worked when handled by a single or very small set of entities. How would the proposed TLD fare any better?

Dick Hardt said something in our interview that I think really hints at a better solution that we see very few people pursuing. If the identity data we give to banks and the like were reduced in its value by a mature, identity protocol (machine negotiated, customer auditable, provider accountable, etc.), then that would direct take on the single greatest incentive phishers have.

As long as this data remains such a juicy target, i.e. it has general value outside of the specific relationship with a single vendor, then phishers will always find ways to surpass defenses and barriers. I am not arguing against making it harder for them to do so, but I just don’t see how the cost of setting up a new TLD is worth a very slight, if any, benefit.

Oh, yeah, the .xxx connection. Like The Treachery of Images, simply saying it is safe does not make it so. And once the system is gamed, is a substantial risk. And, like the .xxx TLD, the converse is also true–just because it does not say safe, or xxx, doesn’t mean that is any more true, either.

Technorati Tags: consumer rights, malware

Even if this proof of concept didn’t require alternate firmware, that is running Linux on the iPod, without a persistent and direct internet connection, I think malware for a PMP is a stretch at best. Far more likely, especially since it has already happened, is PMPs being vectors for PC virii. Remember those players that were infected at the factory? Like a carrier, the players were unaffected but infected PCs once they were attached to sync. That’s just a lot more practical than attacking a device that doesn’t have any useful resources it can yield to an attacker and where the channel for executing the attack is intermittent and conditional.

Technorati Tags: malware