Jürgen Pabel's Blog

That's all Folks!

2011-04-30T16:40:01+02:00

It's been a fun ride but it's time to move on: after almost 10 years I am leaving Akkaya for some new challenges as of tomorrow. Thus, I will not continue this blog anymore. I hope you've enjoyed reading my blog.

The fate of this blog is not entirely decided as of yet: it'll probably remain online but be marked as "archived" shortly. No further comments would than be allowed - so take your chance now if you want to leave some last notes for me and others to see.

I will start a personal blog at http://juergen.pabel.net/blog/ shortly that will be very similar in spirit to this one.

I would like to thank my now ex-colleagues at Akkaya for everything and wish them and you all the best.

Jürgen

TokenTube presentation at GUUG FFG

2011-03-25T15:54:47+01:00

I just completed my presentation about TokenTube at GUUG FFG 2011. Everything went well and interesting questions were asked. The slides are in german and can be downloaded here

Karma bugs

2011-01-31T00:47:41+01:00

Last week I brought an old institution back to life: "karma bugs". Let me explain.

Using a revisioning system is a good idea for any software development (ie: subversion, git or anything like that). Using a change management system is another (ie: bugzilla, mantis and others). Establishing procedures to track source code changes to bugs/change requests is even better. Simply said: every commit requires a (valid) issue number in the check-in comment.

That procedure is easy to follow most of the time in software development. However, especially small things that need to be done shouldn't require developers to create an issue in the change management system in order to fix whatever little tidbit needs attention. Examples could be spelling errors in messages, documentation enhancements, additional unit tests and stuff like that. Noone wants to do these little things if the overhead for doing these is a burden (as creating a proper entry in a change management system usually is).

The "karma bug" is a pre-created issue in the change management system that all developers can reference in their check-in messages for all these little good deeds (thus "karma bug"). At the end of the predefined validity perdiod of the karma bug (like a time period or a release target) all commits are evaluated and the developer with the highest score gets a reward. Just how the scoring is done is something that every project needs to determine theirselves. We've used the number of changed lines as our scoring metric, but anything goes.

I've seen "karma bugs" work wonders for projects both in terms of developer acceptance (with respect to integrating revisioning and change management systems) and even code quality (because doing good deeds might yield rewards).

FFG 2011 - TokenTube presentation

2011-01-23T21:08:27+01:00

My presentation about TokenTube has been accepted to the German Unix User Group's (aka "GUUG") "Frühjahrsfachgespräch" (spring conference). The event will take place in Weimar at the end of march.

I agreed to submit a paper for the proceedings: yet another task on my to-do list.

Android unlock pattern insecurity

2011-01-17T22:07:07+01:00

Last year a group from the University of Pennsylvania analyzed the security of Android's gesture unlock with respect to screen residue ("smudges"). Their basic observation was that the fatty residues left behind by fingers are visible for long times and allow others to recover your unlock pattern just by looking at your mobile's touchscreen.

One easy solution to this issue would be to add random start and finish points into the unlock pattern. Users would have to begin at a (randomly selected and highlighted) start position in the grid and draw (any) connection leading up their own pattern's starting position ("prefix"), draw their pattern and supplement it with (any) connection finishing at a (randomly selected and highlighted) finish position in the grid ("suffix").

Let me illustrate. The first image shows the "original" unlock pattern while the second image adds (rather trivial) "prefix" and "suffix" legs.

Picture 1: the "original" unlock pattern starts at (x=3,y=1), goes to (x=1,y=1) and finishes at (x=2,y=2).
Picture 2: the "new" unlock pattern starts at (x=3,y=2), goes to (x=3,y=1), continues to (x=1,y=1), over to (x=2,y=2) and finishes at (x=1,y=2).
Thus, the random start point in this example is (x=3,y=2) and the random finish point is (x=1,y=2). Obviously, most times randomly selected start and end points will make the effective unlock pattern a little more complex then in this example.

Keep in mind though, that not only will the start and finish points be random: the user is entirely free to chose any path for either leg - as long as it ends up where it's supposed to. That should be enough to cause smudge mayhem and thus destroy any otherwise dominant smudges on the touchscreen.

Randomly generated PINs

2011-01-07T17:20:58+01:00

I've just got a new banking card ("EC-Karte") and my new PIN. Surprise: my new "randomly" generated PIN is the same as the "randomly" generated PIN from one of my previous cards.

I've had quite a number of cards over the years (obviously, they don't like me sitting on them when they're in my wallet) and have observed this reoccurance of same PINs a few years ago. However, back than I didn't keep record of which card at which time had which PIN; it was more of a faint recollection like "hey, didn't I already have this PIN in the past?".

As of today I have proof (as in documentation) that the "randomly" generated PIN for my new card is the same as the "randomly" generated PIN from my card issued in 2007. Obviously, I've already changed the PIN using the online banking system to something else.

All in all, I would say that with the ~10 cards I've had over the last 15 years I've only seen about 3 (at the most 4) different PINs assigned to me. I guess they've adopted Debian's PRNG implementation long before even Debian did.

Self-induced X.509 validity issue solved

2011-01-06T18:09:27+01:00

What happens if you have a CA hierachy and one of the intermediary certificates expires? With good planing, nothing should happen: one generates a new intermediary certificate and all future certificates are signed using that new intermediary certificate. Without good planing (and proper execution), it's a big mess. This is my story...

For clarification, I'll refer to the (self-signed) root CA certificate as "root" (by X.509 extension, this certificate is marked as being capable of signing it's own sub-certificates and thus becomes a "certification authority"/"CA"). The "root" certificate is used to sign the "intermediary" CA certificate (this certificate is also "marked" as being capable of signing it's own sub-certificates). The "intermediary" CA signs any number of "entity" certificates (which lack the X.509 extension marker and are thus not capable of signing any sub-certificates).

Proper certificate planing mandates that the validity of all involved certificates should be "inclusive": the validity of the "intermediary" certificate is entirely within the validity of the "root" certificate and all "entity" certificates are created to be valid within the validity of the "intermediary" certificate only. However, adhering to this plan is not trivial: it requires a properly timed transition phase in which a successor "intermediary" certificate is created before the expiration of the current "intermediary" certificate. Also, all "entity" certificates need to be regenerated using the successor "intermediary" certificate. The deployment of those new certificates needs to occur before the expiration of the current "intermediary" certificate. Thus, the current and successor "intermediary certificates need to overlap in their validity.

What happens proper certificate planning didn't occur? A certificate hierarchy that is not "inclusively" valid leads to a situation in which the "intermediary" certificate expires while "entity" certificates are still valid. The issue is that certificate validation fails because the "intermediary" certificate has expired. Renewing the "intermediary" certificate is the correct solution, but: while a regular certificate renewal (not neccessarily but quite) commonly implies the continued use of the same "intermediary" key it slightly changes the identity of the "intermediary" certificate. While the certificate's subject (distinguished name) can - and should - remain unchanged, it's the certificate's serial number that changes. This wouldn't be an issue, if the "entity" certificate didn't include the serial number of its "parent" as part of the parent's identity in the "Authority Key Identifier" extension:

[snip]
            X509v3 Authority Key Identifier: 
                keyid:D4:E6:B9:D9:FC:B4:9B:B2:FD:08:FB:A6:31:CC:88:FD:1E:30:1C:4F
                DirName:/C=DE/ST=NRW/L=Koeln/O=Akkaya Consulting/CN=intermediary/emailAddress=intermediary@akkaya.de
                serial:02
[snip]

A "standard" renewal of the "intermediary" certificate implies a new serial number for the "intermediary" certificate and thus the validation of the "entity" certificate fails because either the (old) "intermediary" certificate has expired or the (new) "intermediary" certificate's serial number does not match the serial number specified in the "entity" certificate's "Authority Key Identifier". Doh.

The question is how to renew the "intermediary" certificate without issuing a new serial number. The solution is actually quite trivial (but not-so-trivial to find):

openssl x509 -in intermediary_old-cert.pem -out intermediary_new-cert.pem \
             -CA root-cert.pem -CAkey root-key.pem \
             -CAcreateserial -CAserial /tmp/dummy-$$.srl -set_serial OLD_SERIAL \
             -days VALIDITY_IN_DAYS_FROM_NOW

Problem solved and solution documented: yeay.

AXcrypt for Linux

2011-01-04T20:52:18+01:00

A new year means new ideas for my todo-list: a Linux implementation for AXcrypt, complete with Nautilus integration and all.

Unfortunately, it looks like porting the Windows implementation won't be easy since it makes use of some Visual C++ specific features and libraries.

After the FrozenCache presentation

2010-12-31T15:58:54+01:00

A couple additional notes regarding to my presentation:

I've uploaded my slides to the presentation page
Please give some feedback if you attended or watched the presentation
I've found a recording of the presentation

I would like to thank everybody for the great questions during and after the event. Also, it was really interesting to talk to the Mandos guys afterwards - you guys are great and you're software is direly needed.

FrozenCache at 27c3

2010-12-29T03:10:12+01:00

My talk has been prominently mentioned/described on the CCC events page. Whether that means that resident hackers will skip out on hacker jeopardy (same timeslot) remains to be seen.

StressCon

2010-12-27T00:39:05+01:00

My stress level has been continuously high over the course of the last months. Only for the last two days I've been able to back off a little bit. At some point I've jokingly coined the term "StressCon" to indicate my current stress level. StressCon is supposed to indicate the level of outstanding work in relation to its priority and deadline.

I was thinking of creating a website, widget and all those other goodies that you'd expect. Unfortunately, stresscon.com is already taken (for an entirely different purpose).

For now, there's another task on my immediate to-do list: my upcoming presentation at 27c3 (and there's plenty of work left to do).

Hash based One-Time-Passwords

2010-11-16T01:47:41+01:00

I keep getting asked about hash-based one-time-password mechanisms, so I decided to write-up a little blog entry.

First, let's take a 10-mile-high look at hash functions, willingly ignoring all security-relevant aspects. One of the traits a cryptographic hash function should exhibit is that for an input value X an output value X' is computed, which can not be used to deduce the original input value of X. For example, given the input value

X = 4711

then a pseudo-hash function could be to just add up all the number's digits. Thus, this pseudo-hash function would yield the result value

X' = 13

because 4+7+1+1 equals 13. However, given the result value 13 one can not deduce the original input precisely (other input values will also yield 13 but we'll ignore this aspect for now). This computation is employed recursively in hash-based one-time-password algorithms: given a passwort of

X = 74117101114103101110809798101108

than the first iteration yields

X' = 88

and the second iteration produces

X'' = 16

while the third iteration returns

X''' = Y = 7

and we'll stop here for the demonstration purposes (and because we can not proceed in a meaningful manner with a single digit value).

Now, let's construct our one-time-password mechanism using our pseudo-hash function: the user enrolls by providing the n'th hash of his password to the server. For our example, let n be 3; hence, our user enrolls by submitting n=3 and Y=7 to the server. The user is subsequently able to authenticate by sending n=2 and X=16 to the server: the server validates that the hash value of X (-> 16) equals to the stored value of Y (-> 7) and since that is correct it now stores n=2 and Y=16 in its database. The next user authentication would send n=1 and X=88 to the server and the validation would pass once again. However, at this point our one-time password logic has reached it's practical limits because n would be 0 next and thus the original password would have to be sent to the server (which we don't want to do).

Real one-time-password implementations commonly use values of 500 or even 5000 for n. Therefore, they allow a feasible number of successful authentications before requiring a password change. A beneficial trait of real cryptographic hash functions is that they (usually) produce results of a constant length. Thus, the length of the inputs and outputs remain constant (whereas our cross-summing approach requires ever increasing numbers for every increase in n).

Last - but definitively not least - we must also realize that cross-summing lacks (at least) two important security and cryptographic traits:

it's not collision free: for any given Y a (rather random but) valid X is easily computed and that number could (fraudulently) be used for authentication,
it's enumerable/brute-forceable (unless X is reaalllly large and n is reallly small and thus impractical to handle).

That's it - well, not really: many other security aspects need to be addressed, but an entirely different blog entry.

The transport encryption gap

2010-10-23T02:26:55+02:00

Although I initially had my reservations about the increased use of client-side Javascript in Webpages (which is in fact a significant security risk as with XSS injections) there're new opportunities for additional architectural security "features" that websites can implement. What I am talking about is the ability to use client-side computational capabilities to establish an additional cryptographic security layer. For example, take the "traditional" (albeit mostly outdated) website architecture:

This scenario implies that any employed transport security (HTTPS -> SSL/TLS) provides an end-to-end protection for any data users submit to the website because the webserver in effect would terminate the SSL/TLS connection and process the data itself (ignoring any security issues relating to persistance). However, because SSL/TLS termination is computationally expensive most major websites deployed dedicated systems to terminate the SSL/TLS connection in order to offload the cryptographic operations to a dedicated (usually proprietary) systems:

However, most often websites implement a multi-tier architecture in which the webserver is separate from the application-server (which runs the business logic) like so:

While the use of SSL/TLS terminators and application-servers makes perfect sense from a system-architectural perspective it introduces an additional security issue - the "encryption gap":

This might not seem like a significant issue because the prime purpose of SSL/TLS is usually to provide protection for communications spanning insecure networks (ie: the Internet). However, even "internal" networks are more often than not rather not-too-secure because many different parties might obtain access to the network communications between the SSL Terminator and webservers as well as the network segments between the webservers and the application-servers.

The aforementioned opportunity for improving security is that the presumed client-side computational capabilities (Javascript) can be employed to implement an additional cryptographic layer in order to provide an effective end-to-end protection for data transferred between the client and the application-server:

Naturally, this assumes that the application-server implements sufficient safeguards for protecting the data it processes - but that's an entirely different story. What's surprising is that this additional security layer is virtually never deployed, although ready-to-use implementations (libraries) exist. My assumption is that this is because they aren't bundled in major application frameworks just yet and most application architects are unaware of the possibilities.

I think I've established the conceptual issue at hand - let's get to the practical part: what ready-to-use implementations was I referring to? The underlying and (cryptographically) established protocol is the "Secure Remote Password" (SRP) protocol. Implementing SRP requires a change as to how one approaches user authentication: usually the submitted password is matched against a record in the application's database (which is hopefully a salted and hashed representation of the user's password) in order to evaluate the validity of the submitted user credentials. The SRP's core paradigm is to shift away from this compare-and-decide approach and towards a cryptographic proof-of-knowledge approach. The benefit to this approach is that a by-product of this cryptographic verification can be used to establish a shared secret know only to the client and the application-server. This shared secret can than be used to encrypt any sensitive data within the SSL/TLS layer in order to prevent interception in between the SSL/TLS Terminator and the application-server - thus closing the "encryption gap".

An exceptional demo page is provided on the SRP's homepage. It requires Java but is well worth the effort since it neatly details the involved computational steps. Lastly, let me point you to the promised ready-to-use implementations:

SRP's "links" page lists several implementation by programming language
Denksoft's PHP implementation (I really don't know why it isn't listed on the SRP's link page)

SELinux

2010-10-20T19:24:34+02:00

I've come across a great resource for SELinux: http://selinux-mac.blogspot.com/. Especially the 10 part SELinux tutorial is recommended for anyone new to SELinux: http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-one-confined.html.

Secure PIN entry and cheap RFID readers

2010-08-25T00:14:12+02:00

The German government will start issuing national ID cards equipped with RFID chips later on this year. One of the proclaimed scenarios is to use it with a RFID reader for identification and/or age verification on the Internet. To promote adoption the government will distribute one million USB reader devices for free upon request. One catch is that these reader devices are simple RFID reader devices - they lack essential security features like a build-in keypad for secure PIN entry. Rather, the PIN is entered into a software running on the computer via computer's keyboard and relayed into the RFID card reader. Any computer security expert will tell you that this is a fairly risky endeavour: the PIN might be intercepted during entry on the computer if malware is present on the computer.

Obviously, the question to ask is how can such reader devices be designed to be more secure and still be manufactured cheaply? Here's an idea: embed a USB host port and a simple microcontroller on the RFID reader device and connect your USB keyboard (assuming a non-laptop computer) to the reader device (instead of the computer's USB port). In normal operation mode, the reader device would relay all input from its attached keyboard to the computer's USB port; thus, the reader will act as a simple data relay. However, any time an application issues a request to the ID card and the user is asked to authenticate by entering their PIN than the reader device could choose to not relay key input to the computer but rather re-route (for lack of a better term) it to the RFID interface for authentication to the ID card.

I'm not going to delve into technical details right now, but I'm sure such a design would be resistant against PIN interception if implemented correctly. Leave some comments and I'll detail this idea further (multiple USB device classes, driver implementation aspects, etc) - I won't bother otherwise.