A secure democratic Net is a fundamental right

But some of them (including the one from the Belgian official Privacycommission who points out that the readers that are used have NO legal basis for the moment) are quite interesting. The details are what it is all about.

• Introductie (Vincent Naessens, KaHo Sint-Lieven)
• Adder(s) in het e-ID gras (Willem Debeuckelaere, Voorzitter Privacy Commissie)
• The Hitchhiker’s Guide voor de e-ID (Peter Strickx, Chief Technology Officier Fedict)
• e-ID toegangscontrole voor beperken van toegang tot bedrijfsparkings en containerparken (David Maelfait, Alphatronics)
• e-ID kaartlezers en e-ID software ondersteuning (Johan De Vriendt, Arena Solutions)
• Toepassingen met e-ID handtekeningen (Frank Delanghe, DSoft)
• Een e-ID gebaseerd ticketing systeem (Jorn Lapon, KaHo Sint-Lieven)
• eHealth-toepassingen en het gebruik van de Belgische elektronische identiteitskaart (Frank Robben, Administrateur-generaal eHealth platform)

When we published last week the news that we found some good alternatives for the open source middleware for the EID if you didn't want to take any chances and wanted to invest in a secure smartcard environment, one of the programmers posted the following reaction.

" If you have the money, you don't have to use the opensource solution from FEDICT if you want to be absolutely sure.

I always wonder how long such FUD campaigns will last and what drives it? Of course I for one welcome other eID solutions since it increases diversity. This definitely has a positive impact on both probability that a system is being hacked and payoff once a system has been hacked. The probability for security weaknesses being exploited decreases once more eID solutions are available as the competition among these eID solutions will definitely have a positive impact on the code quality. As for the payoff once a system has been hacked we can also state that diversity reduces the number of systems that are vulnerable to a certain security attack on an eID solution. As security can be roughly defined by probability times payoff, diversity will have a positive impact the security property of eID solutions. But to state that commercial eID middleware solutions are more secure is somewhat far-fetched. The reason why I open sourced the new eID Applet is because I don't believe in 'Security through obscurity' and I want to invite security researches into constructing alternative viable eID solutions.

Kind Regards,
Frank.Frank Cornelis  info@frankcornelis.be "

So we have to respond to some things in it

* First it is NOT a FUD thing. It is based on the experience with only one aspect on the code - the so called firewall and the study from the professors that got some remarks about the socalled quality of the code and some of the mechanism (the attention to those remarks was only made here - as usual).

* there is no drive behind it, no dark forces or commercial interests, just trying to keep the discussion going and wanting to drive the security and the discussion even further - because if we stop it, who will continue it ? And if we look at the way people are handled here when they try to show mistakes and other conceptual dangers with the middleware, than you can't speak about an open and professional discussion. And what is open source if the security of the source can't be discussed in an open process ? And in which the upgrade to the last version is even worse than the one before ?

* so we think by talking with a lot of other people that a lot of people are looking for other solutions and want some middleware that is secret, but that can withstand all the security tests, also those from Microsoft .........

Because what is the security of a system in which the middleware or the hardware reader aren't secure enough ? Open Source or not, That is not important because that is an ideological question, not an operational one. An operational one is how you check the code with different attack and analysis tools and how you permanently revise, upgrade and patch the software as efficiently as possible. And I am not saying that all commercial secretive code is good code. It all depends on the security-operations that are used before the code is used for real products.

and yes we want more commercial adaptions for the EID cards from worldwide known companies who follow standards and have internal check processes and external community programs and so on. There is an enormous market over here for such product. So let them come and let the FEDICT middleware be a proof of concept that it is possible but I am sure there are other firms that can deliver other ways to integrate the EID in a secure way in a secure process.

If you don't trust an open source middleware or just want to be compliant in your infrastructure from end to end there are products (middleware) that incorporate or use the EID but just as an card and use it in an secured and compliant environment.

These are commercial products but as they are used in high secure environments they have to protect the authentification and the data on the EID in a better secure way.

Some security products and installations that let you use EID also use these commercial middleware installation instead of the FEDICT software.

one example is this

If anyone has a list of commercial security compliant EID reader middleware, this may be interesting

If you have the money, you don't have to use the opensource solution from FEDICT if you want to be absolutely sure.

The presentation in 63 slides shows in a detailed but very complete and comprehensive way (for security and IDM people) how the encryption (PKI) of the EID in Belgium is organised. It doesn't talk about any weaknesses or other conceptual or political questions one may have, but on the basis of this you can already have a theoretical idea about how it should work in theory.

It is very interesting to read in the last slides he talks about the requirements for it to work securely but as nobody is responsable for certification one can ask who will do the monitoring and testing.

But it is a document one should have read if you are interested in the future of our EID. Any remarks are welcome off course.

Introduction to Belgian eID cards, presented at K.U.Leuven, 27 April, 2009

First let us agree about something. Security means that something is certified, controlled and can be adapted and secured afterwards and that this done and rechecked by a transparent, frequently updated and outsourced process run by professionals and independent securityresearchers.

Secondly there is nobody that says that the EID an sich as to be abolished. The problem is that the card - because of its increasing importance - needs to have that public and transparant securityprocess. This is not the same as making your source Opensource. It is not because your source is opensource that 'automatically' your code and process (ex incident handling and patching) is secure an sich. It doesn't even mean that your code has been revised by the most stringent standards by the community. In Belgium this last thing is absolutely NOT the case becuase the community has been blackmailed into silence by the very vague and dangerous cybercriminality law (and a total lack of other independent places where you can deposit this information safely without risk for your career or name in this small country of ours). For the record we have already shown that we know how to protect our informers and how to get information to the right persons in the right places without publicizing it immediately.

Thirdly you don't have to shoot the pianist but you have to listen to the music and forget the pianist even if he or the band has no name. Discussions should be about the facts not the persons who are posing the questions.

Some facts

* Since the vulnerability that has been published last year a patch has been published 6 months later but that shows some conceptual errors that can pose problems for your security of your data on that card. Meanwhile a browserversion of the EID Middleware has been published - even if the banks are going from browserbased authentification to application/cardreader based double authentification. Securityresearchers and hackers can download the code and test or adapt it at will. There is no certification of your code and how secure your implimentation is.....

* We have published last year that taxonweb (the online tax service that has been used by over a million people) can easily be phished. Forgive us if we are wrong, but we don't see much difference since than.

* there are no public norms or standards, there is a private book with some best of practices from some years ago, but if you are looking how to implement this securily and how to let it be certified as safe you are looking at the wrong place.

* there is no securitycertification of the readers that could be used. Some of those failed some securitytests that were done last year by some amateurs. I am holding my breath if real securityresearch is done against them.

* And so I can go on and on.... and on and on...

And yesterday I was between astonishment and anger when I saw on television that they want to use it for .... safe shopping. This card can't be used for safe shopping. In fact this card can't be used for anything webbased if you want to implement normal securitystandards for banking, shopping or real authentification.

The card IS safe if you use within a secured network or on internally secured machines (like machines to print administrative forms) at the present time. This changes totally if you use it on the web for anything more than stupid things. (except if you use VPN links or highly secured specified connections).

My astonishment with using this card for shopping is that now the card becomes really interesting for IDtheft. As long as it was only an administrative authentification for administrative procedures intercepting the information was only useful for espionage and blackmail and getting more information to bypass anti social engineering questions for example where do you live etc...). Once you can use it for financial transactions and payments the card itself and its digital information on that card become more than interesting. And even more as its security is that like those of the bank and creditcards (and even those are broken or intercepted on an unprecedented scale).

It is even more astonishing as our greatest fear in the beginning of last year was that hackers or digital mobbers would constitute crime databases in which they would regroup the stolen financial information, the email passwords, the passwords for ebay or online shopping portals and so on. Apart this information is only worth pennies, but if you could re-organize it by person and profile it it is much more worth. Some first examples of such databases (although primitive) were found online last year. It shows that ecrime is becoming to look more and more like a normal ITProcess (done by professional ITpeople) and handled as normal commercial datasale processes.

For those databases EID information has now become much more worth.

Before you attack the wild wild west with a new secure solution you should be sure that your castle is secure. Otherwise you will be out on the wild wild west with no secure castle to return to because it has been broken into and taken over.

Someone here around still believes that browsers are secure enough to use and integrate EID and smartcards and the confidential (financial) transactions that come with it.

Some programmers from the official project have launched an open source project on Google to read the EID data with or within a browser.

"The eID Applet is a browser component to enable the use of the Belgian eID card within web applications in the most user friendly way possible today. The eID Applet runs on Windows, Mac OS X, and Linux platforms and supports a wide range of web browsers including Firefox, IE, and Safari. Since the eID Applet can run both with or without eID Middleware installed, it puts minimal requirements on the client browser environment.

The eID Applet SDK allows for web developers to operate the eID Applet with ease while staying focused on the application business requirements. The eID Applet developer's guide is a good starting point for web developers and enterprise application architects.

Make yourself member of the eID Applet group for free support and staying up to date with the eID Applet project. Given the constant security threats in the world of web applications, the security features of the eID Applet are ever evolving. Every day we invest effort in keeping the eID Applet as safe as possible by applying innovative security concepts. Via the eID Applet group we also keep you informed about eID Applet security updates.
http://code.google.com/p/eid-applet"

anyone an opinion (even anonymous) about the security of this code ?

if necessary we can transfer the information without publication (responsable disclosure) as we often do....

You can compare it a bit with the social security number in the US for all transactions with egov applications. The RRN as it is called is part of our EID and is supposed to be kept secret and seperate when the EID is being used.

It is always interesting to read how programmers are pushing the limits and trying to do logical things but that has some dangerous consequences if their belief in the security of the protocols and methods and insider security are proven to be wrong.

So on the EID forum, I have come across this discussion

"

all participants in this discussion are really the highest level of EID advisors running around here.

and as it is mentioned our RRN is also somewhere in the digital signatures of the online mail and forms that are kept in databases here and there.

so we could say there is a certain diffusion of RRN numbers taking place....

2008 started with the month of the EID and we had to close that month down due to a discovery that astonished us so much that we were afraid about what could come next that it was better to inform the responsable people that even those simple bypasses were possible

It was also the year of the first critical report - even if it could go a bit further and was stonewalled by propaganda and a gaff by some politician that diverted the attention.

The update that was published several months later seems even more flawed and for the moment we don't understand what is happening and are utterly confused between middleware, driver and security and quality controls and are not sure about what people are talking and what will be the way forward.

This year also showed that there is a total lack of opennes and audits and research for a project that is so important for our society, privacy and industry.

 11/11/08 12:15 comix : belsec birthday and EID (Electronic Identity Card)

11/11/08 12:00 Exclusive : EID : Has Microsoft rewritten some code ?

26/10/08 22:58 New EID privacy protection already bypassed ? 

16/10/08 16:14 Massachusetts Issues Comprehensive ID Theft Prevention Regulations 

19/10/08 23:24 hacked Cert-ID service yes really.... 

19/10/08 23:39 workshop voor veilige ontwikkeling EID 13 november 

16/10/08 16:52 EID and Ehealth : introduction (presentation) 

30/09/08 14:47 E-passports can be falsified without any alerts going off, make your own 

26/09/08 12:59 E-land archive : Vragen bij de EID deel 5

26/09/08 12:59 E-land archive Vragen bij de EID deel 4

26/09/08 12:58 E-land archive Vragen bij de EID deel 3 

26/09/08 12:55 E-land archive Vragen bij de EID deel 2 

26/09/08 12:54 E-land archive Vragen bij de EID deel 1 

  20/08/08 14:12 the new Belgian EID middleware is nowhere to be seen 

10/08/08 21:19 Belgian RFID passport can be tampered with without much risk ? and 38 others....

25/06/08 09:49 EID not integrated in MSN chat or Microsoft

25/06/08 09:16 EID : the press announcement of the Administration 

13/06/08 09:59 EID : representative Jambon makes some mistakes

13/06/08 09:08 It is now time to make your ideas and proposals about a secure EID public or known

13/06/08 08:43 Onderzoek over EID door Leuvense professoren online 

04/06/08 00:19 Do not place your passport in a microwave - this is official

04/06/08 00:15 Parlementaire vraag over de RFID chip in onze paspoorten 

29/05/08 13:40 EID : I am a man now and a woman online 

02/06/08 10:47 Hoe met social engineering EID en federaal token misbruiken ? 

17/05/08 15:01 EID some articles about the EID video and the privacywall leak 

16/05/08 11:31 EID : we are no part of a hidden campaign

16/05/08 10:50 EID why developers hate security and want to forget about it

15/05/08 12:53 FEDICT responds to the film about EID and some thoughts about the solution

15/05/08 12:16 Book with 'Best of Practices for developers of EID Middleware'

29/04/08 15:26 Huge mistake when using your eID 

18/04/08 14:49 The mifare attack video's (RFID - Smartcard) 

23/04/08 17:17 Belgian EID and the Microsoft question 

18/04/08 09:24 Belgian eID card extension integrated in Apache’s next version

28/03/08 19:43 Vulnerable EID login servers without monitoring

28/03/08 19:25 EID replacing the root certificates and rootservers 

20/03/08 13:55 EID BEST PRACTICE TO KEEP ALWAYS IN MIND

18/03/08 15:05 EID must read articles 

13/03/08 15:01 RFID access cards are hackable 

13/03/08 14:32 Roel Deseyn stelt parlementaire controle op EID voor 

07/03/08 11:57 Will our EID have medical data or not ? 

03/02/08 09:39 two new action buttons safe internet and private EID 

19/01/08 10:45 Belgian E-ID Nr 12 some basic guides by Marc Stern 

13/01/08 01:04 Belgian E-ID Nr 11 : keyloggers work with E-ID 

03/01/08 16:45 Belgian E-ID Nr 3 : read any E-id you have 

03/01/08 13:16 Belgian E-ID Nr 2 : what does Privacy International think ?

MD5 is a encryption method that has been broken before and as such gives not much protection to your data or code if you use MD5 to protect (hide) it from external sources.

This is what a specialist told us about EID and MD5 as we asked him the question because MD5 is being routed out of codes and transactions around the world and as Microsoft has said that MD5 has no place in the Secure Development Lifecycle.

- eID supports signing mechanisms using SHA1 or MD5 or RIPEMD but it
depends what the application is asking for.
- eID files:
  EF(ID#RN) contains SHA-1 hash of the picture
  EF(SGN) contains SHA-1 RSA signature of the other files
  EF(PuK#7 ID) contains SHA-1 hash of the CA Role Public Key
- certificates:
  All personal & root certificates are signed with SHA-1 RSA signatures

So no MD5 unless your own application wants your eID to create a MD5
signature...

my comment : and here is the catch, it accepts to work and transfer data - your data - with an application that uses MD5 even when MD5 is being called unsafe.

EID should begin to think differently. They should begin to think that they will only interact with hardware like card readers that have certified as being secure and the EID will only work with applications that are secure enough and certified as such. Just going by blind trust is being too blind to be trusted. It is not because it works with EID and EID has been totally or not security developed that every application and hardware that has been developed for it is as secure.

This is the reason that the creditcard companies have developed the PCI standard. Because you can only trust the things you can control yourself. The PCI standards is far from perfect, but it has the merit of being there. There is nothing for the EID except some best of practices book that is only available in book and that is even not made by the agency that has brought the EID on the market and is as such not responsable for the book.

If anyone wants to add to this discussion, you can, feel free

Marc Stern did, one of the EID specialists in Belgium, we copy the text here so you don't have to open a new tab to read the posting. It is an interesting read about the importance of security in the process. 

" When we created the specifications of the eID, in 2001, almost all existing applications (browsers, e-mail clients, etc.) were using MD5 only. So we had to support it, although we already knew it should not be used by well secured applications.

I am pretty sure that MD5 will not be supported anymore in the next version of the card - although we may have to support SHA-1 for some time, although it is already considered as weak :-(   Marc Stern   marc.stern(at)approach.be www.approach.be"

Na een jaar aandringen zijn de audit rapporten toegankelijk voor parlementairen. (For our English readers : After a year of asking it is now possible for members of parliament to have access to the official (but secret) audit reports about EID that are already some years old).

Indien het niet voor de inzet van Roel Deseyn was, zou het onderwerp nooit op de politieke agenda blijven staan. We hebben hem daarvoor ook genomineerd volgend jaar en zijn benieuwd wat hij dit jaar zal uitspoken om weer genomineerd te worden :) Er is immers werk genoeg op tafel en bitter weinig echte vooruitgang geboekt sinds de hoorzittingen verleden jaar terwijl de problemen met de beveiliging steeds groter en complexer worden.

Minister Depadt toont heeft hier trouwens een zekere inspanning gedaan om wat duidelijkheid te verschaffen. We bedanken alleszins voor de beperkte openbaarheid van de auditrapporten die kunnen bijdragen tot een betere discussie en inzicht in de problematiek van de EID en de vereisten naar de toekomst toe.

We willen er echter wel op wijzen dat er misschien toch nog fundamentele problemen zijn met deze upgrade want wat als antwoord wordt gegeven is zelfs volgens de eigen informatie van het rijksregister niet helemaal correct. Lees maar eens deze postings.

We hopen echter vooral dat Minister DePadt niet de hardnekkige ontkenning van zijn voorganger zal volgen maar de problematiek met verantwoordelijkheid, rust en leiderschap aan de ene kant en openheid en kritisch debat (een liberaal principe, toch) aan de andere kant zal tot een goed einde brengen.

Misschien hebben we geen Marshallplan nodig, maar een plan Depadt. De centrale vraag in dat plan is er in dat plan niet alleen plaats voor kwaliteitscontrole, processen en procedures maar ook voor externe testen, kritiek en debat. De electronische identiteitskaart is te belangrijk om enkel en alleen aan de techneuten over te laten.

We hopen dus op witte rook tijdens deze wittebroodsweken.... :)

All our EID research http://belsec.skynetblogs.be/tag/1/EID

Parlementaire Vraag EID (page 44)

not so simple

they say configuration not in order (that is new to me) and give some links to pages that don't exist anymore  or just say something I can't do anything with

or give warnings like this

It is assumed that you have ready a document to sign (on your hard drive).


1 - First, select the file to sign by clicking the "browse" button.

2 - Then click the button "I am ready to sign". After a short time you document is converted in pdf format (this time depends on the size of your original document), a window opens and displays your document.

3 - Scroll to the last page of your document where are located the signature zones. In this beta version of the service, there are two areas of signature. (If you need more than two signatures, please let us know). Click on one of the signature rectangles on this the last page to sign. Then enter your PIN code, as requested.

Done, the document is signed including a time stamp in the PDF! Save it on your disk and / or transmit it to the next eventual signing person.

https://signbox.eidcompany.be/

now we need only more privacy, security and certification. EID is a great idea if one can assure the security and privacy completely. The user is interested in something that is secure, not something that is easy. The accent of the upgrade is not enough based upon security and privacy. This is a pitty because the possibilities are enormous. Maybe someone somewhere some day will realise this. First security and privacy than userinterface and than all the rest will follow. Now it is just a bomb waiting for the first real hard attackresearch to happen.

http://eid.belgium.be/nl/Achtergrondinfo/De_eID_technisch... in dutch but the texts of the pdf files are in English and this is the same for the french. I hope everybody speaks and understands english as good as an english speaking person.

I don't

"The tokenD developped by Apple had some serious shortcomings:

Usage of the non-repudation certificate is not possible

Usage of the authentication certificate works for "older" eID cards but not for newer cards "

sorry guys I am not making this up but this is the security warning

but is this based upon an MD5 code (which is unique for each version of an application and changes after each update or change and which would make it difficult to change the name of an application to another for example)

read this and remember the film how the first was bypassed and think again

" Whenever an application, using the eidlib tries to read the public data from the eID card, a warning dialog is displayed, informing the user and asking her/his permission. The dialog is displayed only once during the lifetime of the application" source