Harald Welte's blog
   

RSS

Harald's Web
gnumonks.org
hmw-consulting.de
sysmocom.de

Projects
OpenBSC
OsmocomBB
OsmocomTETRA
deDECTed.org
gpl-violations.org
gpl-devices.org
OpenMoko
gnufiish
OpenEZX
OpenBeacon
OpenPCD
librfid
openmrtd
opentom.org
netfilter/iptables

Categories

Archives

Other Bloggers
David Burgess
Zecke
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Ohloh profile for laforge
identi.ca
twitter
flattr
Linked in
Xing

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom


Contact/Impressum

       
Sun, 30 Dec 2007
Dependency of essential Linux bluetooth features on dbus

Apparently I'm not the only one with outspoken criticism of the BlueZ dependencies on dbus.

I do not want to debate the merits of a message bus system on any system (desktop or non-desktop) and neither do I want to start a debate on how efficient dbus is trying to solve that problem.

However, what I'm fundamentally opposed to is when basic interaction in a network or between a computing device and its peripherals depends on extensive userspace dependencies. Now you might argue that ipsec needs a userspace keying daemon, that routing protocols need a routing daemon, and 802.1x or WPA need a userspace daemon, too. This is not the point. There are very valid technical reasons for doing so, and nobody really proposes that such things should move into the kernel. Also, none of the above-mentioned programs have requirements on other userspace components aside from glibc or maybe some netlink specific library.

Bluetooth however now requires dbus. At least it is almost impossible to do without. I have tried for neverending hours and didn't make it work. Others apparently have similar problems.

If people want to [d]bus-enable their kernel-related tools, let them do it. But please make it optional and don't depend on it. This is just not how things are done in the Linux kernel world until now, and I don't think there has been any debate on whether we really want such a paradigm change yet..

[ /linux | permanent link ]

proprietary MiFARE [in]security finally falling

At a presentation entitled "Mifare - Little security, despite obscurity" at the 24C3, Henryk Ploetz and Karsten Nohl presented about their revelations of the proprietary Philips MiFARE classic RFID system.

As everyone in the IT industry suspected, the level of security provided by such a cheap, low-gate and completely undisclosed system is in fact very limited.

I'm particularly proud that this security research is exactly what Milosch and me originally wanted to enable by creating the OpenPCD and OpenPICC project. We wanted to put easier accessible and open, documented tools for low-level access to 13.56MHz RFID systems.

With a bit of luck, at some point in 2008, it should once again become clear that security by obscurity doesn't work. This lesson seems to be well-understood in the Internet world, but apparently has little penetration into the RFID sphere so far. There are still many proprietary systems whose security relies solely on the secrecy. Once a single person reveals that secret, the system is broken.

I can only hardly imagine the amount of economic damage imposed by the perpetrators of such systems. There are a couple of hundred million MiFARE classic tags on this planet, particularly in public transport ticketing and access control. The vendors of such systems should be blamed for their false claims. And anyone who bought it should be blamed for their blind belief in the claims of profit-oriented corporations without any independent validation or verification.

[ /linux/mrtd | permanent link ]