Dave's Bit Bucket

Mifare Classic cracked

Mifare Classic, the budget RFID card which uses the proprietary Crypto1 algorithm, has been cracked.

While I'm not that surprised that the crack has been achieved, especially given what the disclosure paper says, it would appear that the researchers went to lengths the likes of which I've only seen Ross Anderson and his electron microscope- (and laser-) wielding friends go to, before. In particular, deducing the algorithm by 3D modelling of the silicon from electron micrographs, in order to produce the gate pattern, is a new one on me.

Well done to the team involved, especially over their care to state that only Classic, rather than other Mifare products, are associated with the crack, and that some simple changes to Classic would mitigate against their attack method.

Still, once again, they have proved that if a user has physical control over a device and its operating environment, DRM is a non-starter.

(2008-03-13 09:39:16.0) Permalink Comments [1]

Smartphone? Sun Ray!

As smartphones increase their memory capacity and implement increasingly sophisticated apps, losing (or being relieved of, under duress) your smartphone is rapidly becoming as serious a disaster as losing (or being relieved of) your laptop. Samsung even ran a billboard ad last year around Heathrow, to the effect of "how could people imagine running their lives without their Samsung smartphone" - to which my obvious reaction was, "what happens if someone nicks it, then?"

So, wouldn't it be excellent if - on parting company with your smartphone - you could make one 'phone call, either from home or a public 'phone box, to both turn your missing smartphone into something about as useful to a ne'er-do-well as a brick, and order a new smartphone which, once you receive it and get it registered, will automagically have access to your address book, documents, music, browser favourites, etc?

This is why, what you really need isn't actually a smartphone, but a smartphone-form-factor Sun Ray.

Admittedly, there are one or two downsides to having a Sun Ray instead of a smartphone. You'll need a continuous 3G connection, if you want the unit to be usable wherever you are - this would currently limit the take-up of such a unit to folk who very rarely stray outside metropolitan areas with major 3G coverage, such as central London. However, there's enough such people, that a device could probably be justified.

Also, while the fundamental point of smartphones, and indeed 'phones in general - the ability to make and receive voice calls - is still (AFAIK - my information may now be out of date...) "not quite there yet" on a Sun Ray in terms of being able to do interoperable VoIP, I've seen working VoIP implementations on Sun Ray which aren't quite production-ready yet, but which appear very close to being so.

Still, I've also been doing some thinking. While a bunch of applications specific to smartphone-form-factor Sun Rays would clearly have to be written bespoke and designed for a small-screen user interface, how might "something which is being used as a smartphone, yet which is being served from Solaris" benefit from security technologies such as Trusted Extensions?

Let's start by considering the 'phone book app. If I run my 'phone book app at a label which strictly dominates the label at which the apps which make my 'phone calls, handle Bluetooth connectivity, etc, are made, and I give my 'phone book app the privilege to write data down across labels, then I can set things up such that a connectivity app will only have a number or other connectivity details exposed to it, when a connection needs to be made.

Thus, practices such as Bluejacking would cease to be feasible, as the connectivity apps don't have the privilege to access 'phone book data.

Now, let's consider my 'phone-based web browser, or my 'phone-based copy of iTunes or similar. Where I want to run an app which needs to make external connections and upload data, I could run it at the same label as the rest of my connectivity apps, but give it the privilege to write data up, across labels. For a browser, it would still need to be able to read up (unless I had a separate "Favourites" app, which had the privilege to write URLs down and launch my browser at a lower label, much like GlennF's "safer browsing" prototype) which is, on consideration, probably the better way to go.

In fact, splitting apps into separate "uploader" (with write-up priv) and "player" (run at higher label, with "Favourites" potentially having write-down so that updates may be checked for) components, is probably the definitive way to go.

Suffice to say, if such an environment was built, nobody would be getting their hands on my 'phone book or my copies of S&M or The Ring, any more :-).

Does this have mileage, or what?

(2008-03-08 15:35:51.0) Permalink Comments [2]

Idle Speculations on Type 2 Hypervisors

Following Sun's purchase of Innotek - suppliers of the reasonably-fine VirtualBox Type 2 hypervisor - I've been thinking.

OK, so VirtualBox for OS X is still very much beta - shared folders don't work, and networking only works in NAT rather than Bridged mode - but it's still stable and full-featured enough for me to build a Solaris 10 Update 4 image on top of it, complete with Trusted Extensions. In short, "not bad at all" :-).

However, my thinking is taking me down an interesting line of reasoning. Our press release states that VirtualBox is primarily aimed at developers, so I can only hope and assume that one of the things we are going to do with it shortly in terms of enhancements, now we've acquired it, is thoroughly enhance and decorate it with DTrace probes and providers.

Here's where things potentially get fun - although I must first add, that all my musings in this regard, are currently hypothetical.

Consider a system running Solaris 10, or OS X, as a host OS.

Now run VirtualBox, on top of it.

Now run another DTrace-enabled OS, such as Solaris or OS X (again), in a VirtualBox as a guest OS.

Depending on the degree of complexity involved in VirtualBox, particularly regarding its memory management, I wonder whether it might be possible to DTrace activity in the guest OS from the host OS, potentially without the host OS knowing about it. Being able to do this, could have both good and bad repercussions:

The Good:

• If, from the host OS, you could trap a guest OS' calls to fork() and exec(), you could potentially do Validated Execution for an OS at the hypervisor level, rather than within the OS itself. This not only potentially gives you much greater security - even root on a guest OS can't turn vaidated execution off - but it means that validated execution could potentially be made OS-heterogeneous.
• You could use DTrace to supplant Solaris Audit, gathering audit information about OS activities at the hypervisor level, where nothing which happens at the OS level can touch it.
• It would make for a great kernel-level debugging tool, where you might not necessarily want (or be able) to use DTrace within the OS itself.

The Bad:

• All of a sudden, "Satan's Computer" becomes real. If you're root on the guest OS, you can still have All Manner of Strange Things happen in your environment, if your hypervisor is pwned, and there's nothing you can do about it. For example, if you take a look at Jon Haslam's posting on how DTrace can be used to read an environment variable for an arbitrary process, consider what DTrace might be able to do, in terms of changing the value of an environment variable, under the feet of the application. If you can make such a change without the app crashing, and such that it notices the new value, Life Gets Interesting.

Food for thought. Don't get me wrong, I'm not saying DTrace is bad - far from it - but certain OS-intrinsic capabilities can be considered sufficiently double-edged that the ability to use them at given levels in a virtualised environment, must be very carefully controlled...

(2008-03-07 13:21:45.0) Permalink Comments [0]