To analyze the possibilities and restrictions related to implementing SPOC for EAC, a bachelor thesis study has recently been performed at the University of Skövde and at PrimeKey Solutions AB.
Conducted in three steps, the study begins with an analysis of the SPOC standard. The results of that analysis were used as input to the next step in which several people involved in developing SPOC were interviewed. Finally a case study was made, with the attempt to see whether or not it was possible to use elliptic curve cryptography in an interoperable environment.
The study analyses potential shortcomings in the SPOC specification, which are believed to potentially cause lack of interoperability between different implementations of SPOC. Also studied are potential interoperability issues arising from the use of elliptic curve cryptography (ECC) for TLS communication between SPOCs.
An abstract of the thesis is available for download (English version), as well as the full thesis written in Swedish.
More information
For more information about the thesis, contact the author:
Joakim Kävrestad, joakim.kavrestad(at)his.seFor more information about PrimeKey SPOC and ePassport PKI contact:
Tomas Gustavsson, tomas(at)primekey.se
Posts
2 comments:
I have read the paper and think this paper is a decent summary of the EAC, SPOC, its pros and cons.
First I agree that the SPOC spec is not optimal. But I do not agree to all conclusions…
ECC is a problem, yes. It could lead to interoperability problems if other countries do not implement ECC (we talk arbitrary elliptic curves here). Not much cryptographic software supports elliptic curve ciphers. And just a fraction of these (like Openssl 1.0+, bouncy castle and crypto toolkit) supports arbitrary curves. This makes the SPOC specification harder to implement as arbitrary elliptic curves must be supported. But is absence of required stuff in the implementation specification really interoperability problems? It would be interesting if the paper could point out that two different SPOC implementations (i.e with different crypto toolkits) that both have implemented support for arbitrary elliptic curves still could have problems talking to each other using ECC. Sweden did the first SPOC test against Germany 2011 and did not fail on ECC even though these countries have totally different implementations and crypto toolkits. And yes. It would have been much easier to require RFC defined named ECC curves which would then have been supported in a broader range of softwares. But this does not necessarily make the SPOC specification faulty. Note that arbitrary elliptic curves also MUST be supported when it comes to Basic Access Control and verification of the e-passport signature. So the country still must be able to handle arbitrary elliptic curves anyway, even if it should be removed from the SPOC specification.
Regarding “Sending message to a not available system”… Agree that this is missing, which is not good. But still, there a many ways to handle this as you know the problem exists. But a specification update should be considered by EU. But the problem is that I think the working group behind the specification was disestablished. Not many countries have finished their SPOC implementations as there was no end date set by EU. But now there are more pressure from the EU on the countries to finish the SPOC. So I just guess there are some sort of working group again :)
PS
Why is information left out regarding what people was interviewed? And was the interoperability tested with Primekey products in both ends? If so, then the interopability test is maybe not optimal. But I also understand if that is the case as it’s maybe not that easy to have another partys software to test against in a test like this.
Hi, thanks for you comment.
In answer to your questions; the information is left out to grant the respondents anonymity, i do agree that revealing the respondents could improve the article, but not ensuring anonymity may on the other hand impact the answers.
Yes the experiment used PrimeKey software in both ends and that is indeed not optimal. The initial plan was to conduct a cross-over test with several different softwares but is was not possible to get hold of more softwares within the timeframe of the project since it was conducted as a 20-week thesis project.
Post a Comment