EID : opensource against assured inspection discussion

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.

Comments

  • "I am sure there are other firms that can deliver"

    When I stated that I open sourced the eID Applet because I don't belief in 'security through obscurity' that was only part of the story. The most important argument IMHO even has nothing to do with security at all. I know for sure that other firms [b]cannot[/b] deliver eID products that easily as you stated. Believe me, I can witness a lot of failures in this area these days. If you know that a web browser is (becoming) a major communication medium between citizen and government/business and you then look at the available eID browser components out there and their quality, you must admit that there is something seriously going wrong. One of the reasons is the huge technical barrier companies have to take in constructing such generic eID components. Another reason is that once you have constructed such a component you have to sell it somehow (to compensate for the development effort, and security audit costs if you wish). And this appears to be of a major issue. eID browser components (which are IMHO the trigger to enable broader eID usage) just don't sell that easily. It's a non-sexy product targeting developers. Developers are a kind of clients that classical sales people just don't know how to handle. They're used to target managers/companies/citizens with their talks and shows. The problem is that only developers know what they want from such eID components, but are not in control of the money. Managers generally don't know what such eID products bring, they control the money but just don't buy those things. This niche market is just too odd to make up the development effort. Given the huge development effort, companies just don't productize such components.
    I recently had a meeting at FedICT concerning web browser based eID usage (signatures). One of the developers of this (.NET oriented) company directly acknowledged that this is indeed the biggest issue in the adoption of eID these days. So by making a new eID Applet available via open source we hopefully can take away some of this technological risk that used to scare away companies in the adoption of eID.

The comments are closed.