PTB kann nicht nur Wahlcomputer nicht prüfen, sondern auch Spielautomaten

To my non-german-speaking blog readers: Deep apologies, this one makes more sense in German. It will remain an exception in this blog.

Eine Gruppe von namhaften öffentlich bestellten und vereidigten Sachverständigen hat ein 25-seitiges Positionspapier herausgegeben, das erläutert, wie die Untätigkeit oder Unfähigkeit der PTB (Physikalisch-Technische Bundesanstalt) dazu führt, daß die gesetzlichen Bestimmungen zur Spielsuchtbekämpfung unterlaufen werden.

Die von der PTB herausgegebenen technischen Richtlinien entsprechen nicht dem Stand der Technik. Nicht nur das, sondern es werden auch noch Sachverständige zugelassen, die sich nicht auf dem Gebiet der Informationsverarbeitung (IT/EDV) auskennen.

Das erinnert mich 1:1 an die extrem peinliche Rolle der PTB im Bereich der Wahlcomputer. Zur Erinnerung: Eine Behörde, deren Vorschriften nicht im Entferntesten geeignet sind, die komplexen informationstechnischen Systeme in adäquater Weise zu prüfen. Eine Behörde, die ihre Prüfvorschriften nicht herausrücken wollte, und deren Prüfberichte nicht veröffentlicht wurden - schließlich wiegt das Geschäftsinteresse der Hersteller schwerer als das Interesse der Bürger an transparenten Wahlen, nicht wahr? Erfreulicherweise hat uns das BVerfG bis auf weiteres von Wahlcomputern befreit, und damit auch die Frage erübrigt, ob die PTB qualifiziert ist, Regeln in diesem Gebiet zu erlassen und/oder Geräte zu prüfen.

Man sollte einfach eine Abteilung für die Prüfung der Spielgeräte beim BSI einrichten. Man kann vom BSI halten, was man will - aber man arbeitet dort einfach auf einem ganz anderem Kompetenzniveau. Man sehe sich die umfang- und detailreichen technischen Richtlinien zur De-Mail an. Da hat jemand über Nachvollziehbarkeit und Sicherheit von IT-Systemen nachgedacht, der wirklich Ahnung hat. (ganz unabhängig davon, ob das System an sich für den Bürger nützlich ist)

Die PTB mag sich ja mit der Eichung von Messgeräten und ähnlichem auskennen - zumindest als es noch um mechanische Waagen oder so geht. Der Name sagt ja schon technisch-physikalisch, nicht etwa Soft-und Hardware von Informationssystemen. Aber genau um letzteres geht es bei den Spielgeräten heutzutage: Moderne Computer, mit komplexer Hardware und Software.

Finally: A parseable MAPv1 ASN.1 specification

After way too much work in extracting the ASN.1 text from word documents, learning about the differences in pre-1990 ASN.1 and pre-1990 TCAP with their respective current-day counterpart, some futile attempts with the incomplete ASN.1 grammar files available for ANTLR3, I have finally dedicated the entire day to manually convert the MAPv1 from ETSI TS 09.02 3.10.0 (1994) to work with present-day TCAP and present-day ASN.1 syntax.

The result not only passes the syntax and semantic checker, but it is accepted by the Erlang asn1ct. It has not been tested/validated against any test data so far. Just in case anyone else needs a 'working' version of MAPv1 some 20 years after it was created, I have published the result here: http://cgit.osmocom.org/cgit/asn1_docextract/tree/output/3.10.0

Any bugfixes/improvements/complaints are obviously welcome.

Now I just need to figure out how to properly work with the ROS/ROSE CONTRACT class and TCAP APPLICATION-CONTEXT class to formally describe the various application contexts, their respective MAP operations and associated application context versions. It's actually quite a bit surprising that the ETSI/3GPP don't specify this formally in 29.002. The information is contained in the human-readable part of the document, but not in the formal ASN.1 notation. I wonder why...

Facebook "Open Compute Project" nothing but hot air

There has been a lot of fuzz about facebook's Open Compute Project, and it seems to originate mostly from journalists without much technical skill.

Did anyone actually bother to check what they released? You can find mechanical designs and simple specification data sheets. More or less every vendor is publishing that kind of information, or at least there are common form factors that are specified (like ATX, eATX, mini-ITX, ...)

It is sad to hear that they are 'openwashing' themselves (like BP is greenwashing itself). Specifically, the following portions are not "open":

• Any type of electrical schematics (mainboards, power supply, ...)
• Any type of detailed data sheets or programming manuals on the electronic components used
• Gerber files of the PCBs

So what this really is all about is: Facebook advertising this is our new mechanical form factor, now we want all of you to adopt it, so we can buy cheaper hardware.

Go home, facebook. Come back if you have something _really_ open.

Following up on my GSM MAP archeology project

In the past weeks, I have been blogging about the work I've been doing in trying to recover the earlier versions of the GSM MAP ASN.1 files in order to support it from my own Osmocom Erlang MAP code.

After having gone through the tiresome exercise of implementing a custom MS Word for DOS file parser to extract the ASN.1 definitions from the 3GPP-published DOC files, I tried to feed them into the Erlang asn1ct code generator.

Unfortunately this didn't work, as the old MAP ASN.1 references very old ITU-T TCAP from 1988. So I went to the ITU website. There again a similar story. From their asn1 website section, you can only get the TCAPMessages from 1997. If you want an older format, like the Q.773 from 1988, you can download a PDF file. Most of that PDF file is actual text. But the ASN.1 sections are included as an image, so there is no way how you can copy+paste them.

So there I went, and manually typed in those few pages of ASN.1 source code. After I was finished, I thought I had finally done enough. Writing a word-for-DOS parser, typing in pages of ASN.1 manually. What more can there be? I should be able to finally generate Erlang code for decoding and encoding the respective messages.

But it would be too simple if it was that easy. The 1988 TCAP as well as the old MAP specifications use the ASN.1 "MACRO" construct to define the individual MAP operations. However, as it seems the MACRO construct had been deprecated in 1994 by the ISO in charge of ASN.1. Successive ISO specs for ASN.1 have completely remove the MACRO construct as similar results can be achieved with newly-introduced information objects. So of course, the Erlang asn1ct (as well as other free software ASN.1 tools) does not support such an antique feature.

So here I am in the year 2011, unable to use information available in the public ITU-T and ETSI/3GPP specifications to build a GSM MAP protocol implementation that can deal with the messages that you encounter on real-world SS7 links. I guess there are now the following different approaches to proceed:

• write a converter that translates MACRO into OBJECT
• manually convert the old MAP specs from MACRO to OBJECT
• add MACRO support to current-day ASN.1 tools
• find some old ASN.1 code generators that still support MACRO

All in all, this is a really dissatisfying situation, and I would say it is a failure of the standardization bodies to provide useful versions of their specifications. You cannot remove operations and associated message types from a specification, while in real life even 15 years later a whole number of users still use messages according to those (now removed) definitions. Meanwhile, the old specs are getting useless, because you not only deprecate but completely remove a language construct of the formal specification language used.

This renders the idea of having a formal specification useless. If I first need to write my own converters or manually convert that very same formal specification, errors can be introduced in the translation/conversion process, just as much as errors could have been introduced in manually writing encoding and decoding routines based on a non-formal-specified protocol like most of the IETF / Internet protocols.

Deutsche Telekom tried to register a trademark on netfilter

I am currently doing some trademark related research, and just for fun I queried the database of the DPMA (German trademark and patent office) for "netfilter".

To my big surprise, you can find this record, indicating that Deutsche Telekom AG has applied for a trademark on the word "NetFilter" in July 2006.

I find that quite outrageous, as the netfilter project is using the name since about 1999, i.e. 7 years earlier. To our luck, the trademark office refused the application based on the generic nature of the name, i.e. "netfilter" being too generic for anyone obtaining a trademark on it - at least in Germany, under German laws.

Linux Beer, anyone?

During my trademark research, I also discovered: A German beer brewer (St. Georgen Braeu, Buttenheim) has held a registered trademark "LINUX" from 1999 to 2009. This trademark was restricted to "beverages, beer and other alcoholic drinks".

You can find the respective entry in the DPMA trademark database here.

I am not quite certain whether I would have liked the idea of drinking a pint of Linux or not. It would certainly have been a popular gift to bring to international (Linux, Free Software) conferences.