About the Editor

Roberto has over 25 years experience in the IT field, and has spent the last 12 years working in the intersection of open source software and business development. Roberto has taken an active interest in different open source projects and organizations, he has served on advisory boards, and helped large IT vendors, open source vendors and customers to design and deploy their open source strategies. After serving as Senior Director of Business Development at SourceForge for over 4 years, in 2016 he started a new company called Business Follows, whose mission is to is to help developers, companies and organizations to make Open Source development a key part of their business strategies. He is the editor of commercial open source blog.

The “e” in eIDs is really only as good as the services that the card provides access to–without services, an eID card is nothing but a piece of plastic (with a chip). To enable a card to use services requires software, namely something called middleware that interfaces the web browser to the smartcard. Maximizing service access and thus the value perception by citizens, means to “eID-enable” as many environments and applications as possible.

What will seem natural to most Open Source people out there, but often less so to government organizations, is that a single organization cannot easily support all desirable/necessary cases very easily–this is a simple conseguence of the ever increasing scarcity of resources.

Applied to eIDs, most governments provide eID middleware for the “major platforms” which can range from only Windows to a maximum of Windows, Mac OS X, and Linux on Intel. Do you want to access an eID-protected service from your mobile device running Symbian, or from some embedded device that runs Linux on a Strong ARM processor, or even only from Linux on PowerPC?–well, don’t count on governments to help you out any time soon.

So a key factor to using eIDs ubiquitously, and thus create value to citizens, is to enable third, non-government parties to develop and distribute middleware where it is missing. Unfortunately, this is not possible in every European country. While some national eID projects have published their technical specs from the very beginning, others have treated them as confidential and thus prohibited third parties from filling in the gaps. Considering that ID documents are related to “national security” and that government decision makers more often come from a legal than a technical background, this is not as surprising as it may first seem to computer security experts.

In view of the significant negative consequences of unnecessary confidentiality, it is very nice to observe that decisions can indeed change! Italy was one of the European countries who considered the spec of their eIDs confidential. This has in the past prohibited the support of Italian eIDs on non-Windows platforms. Also, the current middleware [that is part of the pilot project and may be replaced for the general roll out] does not play well with Mozilla Firefox (even on Windows). Thankfully, all these are now restrictions of the past since the full spec was indeed published yesterday. I believe that this is the merit of many unnamed people, acting behind the scenes, who used many ways and various opportunities, invested an enormous amount of personal energy, to drop by drop hollow the stone and remove the rocky mountain that blocked the way to freedom. This is the moment for gratitude and for encouraging others with the message that it is not easy, but it is possible and at times it succeeds.

So what will the gained freedom bring us and the citizens who have an Italian eID in their pockets? Here is my take on predicting the future: In a relatively short time, support for the Italian eID card will be added to OpenSC that already supports most other European eIDs and the American PIV. This will provide multi-platform middleware for use by Firefox browers, Virtual Private Networks, Secure Shell, Linux logon, and other applications. Also, commercial players will more easily be able to provide out-of-the-box eID-support in their operating systems or on their devices (such as set top boxes).

I hope that this foreseeable positive development will become a visible experience that demonstrates the benefits of openness and influence those countries who still keep their specs confidential: The community can amplify resources and thus achieve what a single player (in eIDs mostly a government) simply cannot even hope to do. So let us work on making this a reality, let the community provide significant help in making eIDs a success, and from time to time let us remind people that it is openness that made this all possible.

I hadn’t read your take before doing this, but it turns out to be correct. There is a patch adding support for CNS/CIE, and I hope it gets into trunk soon, so that the next release of OpenSC features support as well.

About two years ago, I wrote OpenSC support for CIE and had also submitted it to the Ministry in order for them to publish it on their open source repository (I had an NDA, never received the spec, and it was never published). Haven’t had time to port it to the latest version and for legal reasons, couldn’t publish it (and the same for my python library to access CIE, pyCIE), but Roberto Resoli (Comune di Trento) has started to work with my old code. But let’s just work together to create a single PKCS#11 for CIE and CNS (the current CIE ARE different from CNS in some respect..). Some people officially involved with CNS are also interested in this work. Let’s join and produce a single well-tested solution.

The CIE filesystem is a great new for everybody, like me and Bud, interested in open source as a way to lower the barrier between citizens and eGovernment. It seems that a lot of already done work is being unlocked (Bud, Emanuele, who else? 🙂 ).
CNS and CIE are indeed different beasts, but they MUST[1] be interoperable.
The main difference, apart form external appearance, is that CIE does not have a Digital Signature service on board, even if the last rules (November 2007, the same that stated the filesystem disclosure)
specifically indicate this possibity.

CNS is not the best practice around, from the Open Source point of view.
It is currently not possible to support it, because some operations (Digital Signature in particular) are protected using symmetric cryptography
(“Secure Messaging”) whose secret keys are embedded in the card, and then in the opaque, proprietary software that deals with it.

The need of protection (but not its implementation) is mandated by an EU regulation about Electronic Signature[2], which sets the level of security (CWA 14169 -> Common Criteria, EAL4+) for “Secure Signature
Creation Devices” (SSCD). Technically, a “Trusted Path” and “Trusted Channel” must be estabilished between SSCD and SCA (Signature Creation Application).
The actual running implementation is such that CNS cards coming from different manufacturer (and even different batches of cards from the same manufacturer!) are not interoperable (even if all the specifications
involved are the same, the secret key is not!).

The corrently under study European Citizen Card proposes a different approach; in related technical (CWA 14890, chapter 8) a protocol involving asymmetric cryptography is outlined, in which the key for Secure Messaging is generated on the fly, more or less in an SSL/TLS fashion.
May be this could be the next step on the way of a really open and interoperable eID infrastructure.

If someone wants to go deep in the subject, i prepared a package[3] collecting several of the regulations quoted here, along with a presentation I made for the last Italian Free Software Conference.

“The complete informatic match between CNS and CIE will assure
interoperability between the two cards and continuity of service
to the user moving from CNS to CIE.”

[2]”COMMISSION DECISION of 14 July 2003
on the publication of reference numbers of generally recognised standards for electronic signature
products in accordance with Directive 1999/93/EC of the European Parliament and of the Council”