Friday, May 16, 2008
Belgian EID Security
Recently there has been a lot of attention in the Belgian security world about hacking the Belgian Electronic Identity Card. I don't get it where all of the sudden this noise comes from. Everybody who knows how to send APDU's to a smart card can readout the identity file (that also contains the unhashed national number) and the address file of the Belgian EID card without entering the PIN code. This has always been like that for applet version 1.0 and 1.1 that is installed on the Belgian EID card. The card was designed like this, so what's the problem?
IMHO it's all about some companies doing a FUD campaign so they can have bigger influence on FedICT (where the money is). Especially given the situation that the people who knew something about EID at FedICT no longer run the show and have started their own company with the most appropriate name ever: The eID Company. This leaves FedICT in a very vulnerable position. One advice to the new guys: stay cool. But then again, I'm not into politics.
Especially since Java6 things have become very easy as it comes to reading out smart cards. In fact, reading out the Belgian EID card directly using APDU's is in some cases easier to me than using the EID middleware. As it is easier to install Java6 on a desktop machine than it is to install the Belgian EID middleware the choice is pretty straightforward when you're dealing with a virgin desktop system. Just go directly to the card via the PC/SC stack.
As an example, let's readout the national number using the Java6 Smart Card I/O API. First of all we need to setup a connection to the Belgian EID smart card.
Now we can send an APDU to the card to select the identity file on the smart card as follows:
Reading out the file can be done by using the following statement multiple times:
The identity file itself has a simple Tag Length Value structure. The national number has Tag number 6.
You know, the big problem with the Belgian EID card is that almost everybody forgot about their PIN code anyway. So for an EID enabled application of the first hour to become deployable you're actually forced to use the Belgian EID card without ever invoking any operation (like the compute digital signature APDU 0x00, 0x2A, 0x9E, 0x9A) that requires a PIN code. Even the security pop-up of the EID middleware about some application that will readout your private data from the card might freak out end users this much that they will flood your help desk in no time. Making the big audience to use the Belgian EID will take some time and will require us (security developers, architects, whatever it is you're doing with this freaking card) to lower the security constraints in a controlled way. Don't try to run before you can walk.
IMHO it's all about some companies doing a FUD campaign so they can have bigger influence on FedICT (where the money is). Especially given the situation that the people who knew something about EID at FedICT no longer run the show and have started their own company with the most appropriate name ever: The eID Company. This leaves FedICT in a very vulnerable position. One advice to the new guys: stay cool. But then again, I'm not into politics.
Especially since Java6 things have become very easy as it comes to reading out smart cards. In fact, reading out the Belgian EID card directly using APDU's is in some cases easier to me than using the EID middleware. As it is easier to install Java6 on a desktop machine than it is to install the Belgian EID middleware the choice is pretty straightforward when you're dealing with a virgin desktop system. Just go directly to the card via the PC/SC stack.
As an example, let's readout the national number using the Java6 Smart Card I/O API. First of all we need to setup a connection to the Belgian EID smart card.
TerminalFactory factory = TerminalFactory.getDefault();
CardTerminals terminals = factory.terminals();
ListterminalList = terminals.list();
CardTerminal cardTerminal = terminalList.get(0);
Card card = cardTerminal.connect("T=0");
CardChannel cardChannel = card.getBasicChannel();
Now we can send an APDU to the card to select the identity file on the smart card as follows:
cardChannel.transmit(new CommandAPDU(0x00, 0xA4, 0x08, 0x0C,
new byte[] { 0x3F, 0x00, (byte) 0xDF, 0x01, 0x40, 0x31 }));
Reading out the file can be done by using the following statement multiple times:
cardChannel.transmit(new CommandAPDU(0x00, 0xB0,
highOffset, lowOffset, 0xFF);
The identity file itself has a simple Tag Length Value structure. The national number has Tag number 6.
You know, the big problem with the Belgian EID card is that almost everybody forgot about their PIN code anyway. So for an EID enabled application of the first hour to become deployable you're actually forced to use the Belgian EID card without ever invoking any operation (like the compute digital signature APDU 0x00, 0x2A, 0x9E, 0x9A) that requires a PIN code. Even the security pop-up of the EID middleware about some application that will readout your private data from the card might freak out end users this much that they will flood your help desk in no time. Making the big audience to use the Belgian EID will take some time and will require us (security developers, architects, whatever it is you're doing with this freaking card) to lower the security constraints in a controlled way. Don't try to run before you can walk.
