11

At my work I deal with the cryptographic aspects of the international E-Passport specification (the crypto chips embedded in your passports, the kiosks at airports that talk to them, and the certificate authorities that issue their certs).

The relevant standards document is BSI TR-03110-3.

Section A.2.1.1. Standardized Domain Parameters provides a list of NIST and Brainpool curves that are allowed. Cool. Section A.2.1.2. Explicit Domain Parameters provides a mechanism for you to use any domain parameters you want.

My question is: Are they on drugs? Coming up with safe domain parameters is non-trivial. I suppose some countries' passport offices have cryptographers on staff who know what to look for in parameter generation, but not all. That seems like an awful lot of rope to hang yourself with for no real gain. Can anyone shed more light on why they would allow this?

Mike Ounsworth
  • 3,717
  • 1
  • 20
  • 29

3 Answers3

12

I don't have any visibility into the BSI standardization process, and so this is a guess; I suspect one of two things happened:

  • This is a potential way to deal with someone figuring out how to break both Brainpool and NIST curves (but not arbitrary elliptic curves; if they managed that, this hook won't help). In that case, if someone did that (or if we suspect they might have), we can update the passports without modifying the spec or the readers.

  • This is a political compromise; some entity with political power pushed it into the BSI spec; possibly because they were card manufacturers that were already using other curves (and BSI decided they didn't want to endorse those curves for whatever reason); possibly because it gave someone a competitive advantage (our password validation equipment does it, our competitor's does not; forcing this in will delay our competitor) or possibly because some bureaucrat got it into their head that this was a good idea.

As for whether coming up with safe domain parameters is non-trivial, well, yeah, it's not something you'd want to hand off to an intern; however the known potential attacks against elliptic curves are well documented; it's not that difficult for someone who knows what they're doing to come up with curve parameters that make all known attacks infeasible. In fact, there's this paper where they suggest literally creating a fresh elliptic curve for every single key exchange.

poncho
  • 154,064
  • 12
  • 239
  • 382
8

Political reasons likely wins. E.g. France has an own set of domain parameters. Note that when the spec was created that the Brainpool curves where rather new.

Generating safe parameters is not trivial, but we're talking countries here. Most of them will simply copy what's out there or buy a solution, but a few of the more advanced ones can try other curves they've generated themselves, in their own secure environments. Note that you'd still use $F(p)$ or $F(2^m)$ curves, so any generic attacks will still be present, whichever curve is used. You cannot just insert one of the "Safe Curves".

It's of course absolute hell to test all possible configurations (which is required if you're building a solution that needs to read out ePassports) and IMHO there are way too many optional elements in the spec. Problem is that setting up a registry among all possible countries - and then updating the software - is next to impossible as well. Otherwise just a number could have sufficed.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
2

Why should anyone be "on nuts" because he gives the system integrator the freedom to choose the curve he wants? If they didn't give that freedom, I am pretty sure that many people would say: "Well, they force us to use that curves. There is surely a backdoor in there!".

On the other hand, A2.1.1 claims that one SHOULD use standardized domain parameters.