cat /dev/braindump

Bei Jens Kubiziel und Fefe gibt es gerade eine aktuelle Sammlung von Blogposts [1, 2, 3, 4] zur Sicherheit von Sparkassenkarten mit NFC-Funktion in Bezug auf die unbemerkte Auslesbarkeit von Daten mit Wiedererkennungswert im Vorübergehen.

Das habe ich zum Anlass genommen, um die sich in meiner Geldbörse befindlichen kontaktlos auslesbaren Plastikkarten mal ein wenig genauer unter die Lupe zu nehmen. Als besonders interessant erwies sich dabei das eTicket-RheinMain, eine persönliche, d.h., nicht übertragsbare Jahreskarte des Rhein-Main-Verkehrsverbund (RMV) auf RFID/NFC-Basis. Zu dieser Karte verspricht der RMV auf seiner Website vollmundig:

Sind auf der Chipkarte auch persönliche Daten hinterlegt?

Personenbezogene Daten enthält der Chip nicht. Es werden nur eine Identifikationsnummer (ID) sowie die für Fahrten mit Bus und Bahn wichtigen Daten - wie Fahrkartenart, Gültigkeitszeitraum und Tarifgebiete - gespeichert. Bei persönlichen Chipkarten werden Name und Foto außen auf die Rückseite der Karte aufgedruckt. […]

Das eTicket RheinMain bietet seinen Nutzern hinsichtlich des Datenschutzes ein Höchstmaß an Sicherheit. Bereits bei der Entwicklung des Tickets wurden die Datenschutz-Aufsichtsbehörden mit eingebunden.

Klingt soweit stimmig, stellte mich aber noch nicht zufrieden - könnte doch zumindest eine eindeutige ID der Karte auslesbar sein, die mich zumindest wiedererkennbar macht.

Also habe ich mir die Karte mit ein paar gängigen NFC-Reader-Applikationen für Android angesehen - die meisten kennen die verwendete Applikation “Verband Deutscher Verkehrsunternehmen (VDV) Card” nicht.

Zum Glück gibt es zwei Applikationen, mit denen sich der Karte ein paar - durchaus unerwartete - Details entlocken lassen:

• mytraQ
• speeKA!

Die von mytraQ auslesbaren Infos schienen noch recht harmlos: Eindeutige (und damit wiedererkennbare) Kartennummer, die Information, dass es sich um eine persönliche Jahreskarte handelt, sowie der Gültigkeitszeitraum der Karte.

Die mit speeKA! auslesbaren Informationen waren dagegen schon interessanter: speeKA! zeigt nämlich direkt einen Hex-Dump des Karteninhalts an. Und siehe da: Inmitten von Zertifikaten und anderen Binärdaten steht doch tatsächlich mein Name im Klartext:

Keine personenbezogenen Daten. Klar. Was bitteschön, lieber RMV, wenn nicht mein Vor- und Nachname, abgelegt im Klartext, ist denn dann bitte ein personenbezogenes Datum?

Was bitteschön hat die angeblich involvierte Datenschutzbehörde denn geprüft? Irgendein Spezifikationsdokument, das im Endeffekt nichts mit der Implementierung zu tun hat? Die Aussage des RMV, dass das so alles schon seine Richtigkeit habe?

Ich bin jedenfalls auf die Antwort des RMV auf meine Anfrage gespannt, wie ich denn ein Ticket beziehen kann, dass entsprechend der Aussage in der FAQ keine personenbezogenen Daten über mich enthält. Ich werde berichten…

Update: Inzwischen habe ich auf dem Postweg eine neue RFID-Karte erhalten, auf der via Funkschnittstelle tatsächlich keine personenbezogenen Daten mehr im Klartext lesbar sind - bei der Erstellung der ursprünglichen Karte sei ein Fehler unterlaufen.

Some laptop users may know the following scenario: In situations where others may potentially gain unauthorized access to your machine, e.g., in public places or in the office, you may want to enable a screen lock shortly after the screensaver kicks in so that the time window during which your system is potentially vulnerable to malicious users stays short (of course, it is still recommended to manually lock the screen when you leave your laptop unattended). However, at home, the need to unlock the machine after some inactivity becomes a little annoying, which makes enabling the locking functionality by default a less desirable option.

Now, what if your laptop could automatically detect your working environment and disarm or re-arm the screen lock depending on its physical location? Well, it can: Turns out there are some nice hooks available to run scripts during various network state change events. The ones that will be of interest for us are if-up and if-down. Apart from that we make the assumption that it will be possible to detect the laptop’s “safe” home location by means of it being signed in to a given WiFi network (identified by its SSID).

Before proceeding, let’s make some further assumptions for the sake of simplicity:

• You are running a recent KDE version (the author uses 4.6.x – older versions may also work, though).
• The paths mentioned in this guide may be specific to Ubuntu/Debian. Your mileage for other distributions may vary.
• You have configured a screensaver through the KDE System Settings to automatically kick in after some time of inactivity.

The portion we will be automating is enabling and disabling the automatic screen lock after disengaging the screensaver using KDE’s kwriteconfig command. To do so, create a new script /etc/network/if-up.d/screenlock and populate it with the following content:

#!/bin/bash
     
SSID=
USERNAME=

/sbin/iwconfig wlan0 | /bin/grep -q ${SSID}

if [ $? = 0 ]; then
    logger "Disarming screen lock"
    su -c "/usr/bin/kwriteconfig --file kscreensaverrc \
       --group ScreenSaver --key Lock false" ${USERNAME}
else
    logger "Re-arming screen lock"
    su -c "/usr/bin/kwriteconfig --file kscreensaverrc \
       --group ScreenSaver --key Lock true" ${USERNAME}
fi

exit 0

Make sure not to forget to configure your user and SSID placeholder at the top of the script.

Also, make the script executable:

sudo chmod +x /etc/network/if-up.d/screenlock

So far, the script is only invoked when establishing a network connection. To also invoke it upon disconnecting, we need to create an appropriate symbolic link:

cd /etc/network/if-down.d/ sudo ln -s ../if-up.d/screenlock .

You can test whether the screen lock is working by manually enabling the locking facility in the KDE System Settings -> “Display and Monitor” -> “Screen Saver” -> “Require password after …”. Test whether the lock is effective by letting the screensaver kick in. When dismissing the screensaver you should be prompted for a password. Now, connect to your WLAN. Retry the screensaver test cycle, which should no longer require the entry of a password. Last, disconnect from your WLAN again to observe the lock coming back.

That’s it. Have fun with your new location-aware screen lock configuration. Of course, further uses of the mechanism can be thought of, such as automatic file synchronization. More to follow in a future blog post.

Before setting up dm-crypt, one is supposed to overwrite the hard disk with random data. As it turns out, this is harder to do than initially expected. Using /dev/random or /dev/urandom as a data source to overwrite the disk will take ages (multiple days) for a hard disk drive of typical size. The same applies to using the wipe command.

Fortunately, there is an alternative available by means of the badblocks command:

badblocks -c 10240 -s -w -v -t random /dev/<device>

This takes approximately four hours per terabyte of data (YMMV).

Source: http://chakra-project.org/wiki/index.php/LUKS_for_dm-crypt

Many people seem to get a productivity boost during the holiday season - open source projects all over the world are pushing out new releases these days. Hash It! is not an exception, so I am proud to announce the availability of Hash It! 1.3.0 for Android, a major feature release.

Most new features introduced with this release improve Hash It!’s usability, such as (optionally) caching the entered master key for a configurable amount of time, so that you don’t have to type it again and again as you hash passwords for multiple web sites. Another usability improvement causes Hash It! to automatically return to your web browser once you have hashed the password without the need to manually hit the back button. Of course, this is also configurable.

While previous Hash It! releases covered the functionality of the original Password Hasher Firefox extension, the Password Hasher Plus extension for Google Chrome introduced a new feature to improve the password strength using a private key. Hash It! 1.3.0 puts in support for this feature and should now again be fully compatible with Password Hasher Plus.

Last, but not least a few bugs fell by the wayside. Sorry, guys… ;-)

Hash It! 1.3.0 is available via the Android Market. Details are also available at: http://android.ginkel.com/

Merry Christmas & have fun using Hash It!, your friendly password memorization brain extension! ;-)

Well, it seems that some ugly bugs made it into version 1.2.0 of Hash It!. Unfortunately, it took five days to notice…

Anyway, a new version (1.2.1) is out now, which should hopefully solve these issues. If any force closes remain, please drop me a mail.

Today marks another important milestone for Hash It!, your friendly password memorization brain extension. ;-)

While you can conveniently use Hash It! from your preferred mobile web browser via its “Share” feature, some people prefer starting Hash It! from the launcher, which requires manual entry of the site tag. So far, Hash It! did not remember these manually entered site tags, which required repeated re-entry of the respective tag over time. To close this usability gap, Hash It! will remember the site tag in a history from this release on. Just type the first few characters of the desired tag and the history of matching tags will be shown. Users concerned with the privacy implications of this feature can easily disable it in the settings.

Furthermore, Hash It! did not support FroYo’s (Android 2.2) Apps2SD feature. While Hash It! is pretty small (< 100 kB) compared to other Android applications (so this feature is probably not vital), I would still like to leave this decision to the end-user, which is why starting with Hash It! 1.2.0 you can move it to your SD card (given that your phone is running Android 2.2).

Hash It! 1.2.0 is available via the Android Market. Details are also available at: http://android.ginkel.com/

Have fun!

A couple of days ago I visited the UK and also took my Android smartphone with me. After accessing some loal .co.uk web sites I quickly noticed that Hash It! would not figure out the right site tag for them when it was invoked from the Android web browser via the “Share” intent.

So, I just rolled an update, Hash It! 1.1.0, which adds support for the most common ccSLDs (country code second-level domains), such as .co.uk, .ac.uk or .com.sg.

Hash It! 1.1.0 is available via the Android Market. Details are also available at: http://android.ginkel.com/

Enjoy!

It has been a while since I last worked on Hash It!, but thanks to the bug report of an attentive user I just uploaded a new version (1.0.2) of Hash It! to the Android Market. Bottom line: Hash It! now works correctly on Android 1.5.

Hash It! is licensed under the GPLv3 and as such comes with full source code for your entertainment.

Further details on how to download it to your mobile phone as well as the changelog are available at: http://android.ginkel.com/

Get it while it is still hot! ;-)

Due to current events I started to think about options for a backup solution that would be able to cope with a complete disastrous loss of hardware. So, off-site storage was warranted.

What I came up with is a backup solution based on Duplicity and Amazon S3.

Storing personal data in the cloud may ring one or another alarm, but with Duplicity the data is safe from prying eyes as all backed up data is sent through GnuPG using public-key encryption before being transferred to Amazon’s data center. You should, however, make sure that one of the private keys used for encrypting the backup is locked away in a safe place, so you have it handy when it is time to perform a restore.

As far as storage costs are concerned, storing 50 GB of data in the AWS S3 cloud for a month costs around 6 EUR, which I personally consider quite competitive for redundant off-site data storage.

Naturally, one drawback remains: Bandwidth usage. It takes a while to load the first full backup into the cloud as the upstream of most DSL lines is rather limited. After that initial load has completed, however, Duplicity is capable of appending incremental backup sets to the existing backup data, so the incremental backups complete much faster.

P.S.: It may sound a little weird that I chose Amazon Web Services as a storage provider after my recent trouble with Amazon.de, but after some thorough market analysis AWS remained as the only feasible option.

As a happy long-term user of the Password Hasher extension for Mozilla Firefox I got used to being able to use different secure passwords per web site without having to take the burden of remembering them all.

When I recently bought an Android-based smartphone I was missing most of that convenience while surfing the Internet from my smartphone as Password Hasher was not available natively on that platform.

Hash It!, an application for the Android platform I developed, is there to bridge this gap: It eases using unique passwords per web site without overloading your brain by generating site-specific passwords derived from a secret master key. It maintains compatibility with the Password Hasher Firefox extension.

Hash It! is free (as in speech) open source software released under the GPLv3 with the source code being available on GitHub.

Further details on how to download it to your mobile phone are available at: http://android.ginkel.com/

Enjoy!

At 26C3 there were a couple of pretty interesting talks dealing with GSM security and how it can be easily broken through active (IMSI catching) and passive (rainbow table attacks on the A5/1 cipher) attacks.

Now, researcher’s are pushing to phase out GSM’s A5/1 cipher replacing it with modern, non-proprietary cryptography as countermeasure to the weaknesses facilitating A5/1’s susceptibility to passive eavesdropping. While this is certainly not a bad idea, it will end up with all but secure GSM calls considering that for GSM calls only the wireless interface benefits from the encryption. It will prevent John Doe from listening to your GSM calls using a wiretapping device placed in front of your apartment, but by no means will it lead to end-to-end security for GSM calls.

So, instead of attacking the wireless interface a malicious hacker would have to turn to the (fixed) telephone network to get hold of your calls.

In the end, only end-to-end encryption of calls will be able to prevent such attacks, so this is IMHO what we should be striving for in the long run.