12 Jan
2011
12 Jan
'11
6:31 p.m.
On Wed, Jan 12, 2011 at 05:57:36PM +0100, Alain Knaff wrote:
On 12/01/11 17:33, Lionel Elie Mamane wrote:
> On Wed, Jan 12, 2011 at 03:15:38PM +0100, Alain Knaff wrote:
>> On 12/01/11 14:46, Lionel Elie Mamane wrote:
> Yes. From the software POV, the SIM-sized
smartcard and the
> credit-card sized smartcard are identical; they present the same ATR.
> The only difference I could see is the size of the keys on it; if
> memory serves me right the SIM-sized smartcards have 2048 bit keys and
> the credit-card smartcards 1024 bit keys.
> I find that rather ironic, as the credit-card
sized smartcards are
> advertised as slightly "more secure" by LuxTrust.
As far as I know, they market it as being "more
professional", not
more secure, and this has more to do with the features that
Luxtrust's PKI supports on the various media, rather than the
intrinsic security. Most important feature here is that the
credit-card sized cards support signature by multiple cards, which
is useful in an enterprise context if signatures of more than one
decision-taker are necessary to validate a given business
transaction.
Oh. Do you have details on that? Can one for example do that for
etat.lu websites (eTVA, RCSL, ...)? We may be interested to actually
do that for certain critical operations.
Moreover, Luxtrust provides a fraud insurance with
their media, and
the amount insured is higher for the credit cards than for the SIMs.
That's probably what I interpreted as "more secure"; if you are
willing to give a higher insurance, it means you consider it more
secure :)
>> Btw, I had a peek in Gemalto's own
drivers (using a crude
>> decompiler), and apparently they heavily use OpenSC themselves...
> However, they do not obey OpenSC's license
fully: they do not give
> us .o files for their binary-only parts, so that we could relink it
> against a newer version of OpenSC, which might actually make their
> binary-only driver work on newer GNU/Linux systems (e.g. it does
> not work with Debian "lenny" 5.0, only with Debian "etch" 4.0).
Weird. I use it on an Ubuntu 10.04, which is also
fairly recent
(came out last year).
But I did notice that opensc based _applications_
cannot use the
Gemsafe PKCS11 module (even on older Ubuntu 8.04), supposedly
because the two copies of opensc "fight" each other (the "dynamical"
copy pulled in by the app, and the static one brought by the PKCS11
module). No such problem exists for apps that don't use OpenSC
directly (such as Firefox).
I *think* it is actually Mozilla Firefox that I tested, but I'm not
100% sure; possibly it was openssl and/or some OpenSC part. The latter
might have been the source of my "does not work on newer system", as
Debian etch happens to have the same (or close) version of OpenSC as
included in libgemsafe, maybe they don't "fight" each other.
Also, legally, their licenses are an interesting mess.
They did
include the LGPL for openSc in their package, but then put their own
license (for the proprietary parts) next to it, and both licenses
basically contradict each other (and there is no text which says
which should count more). I would guess, in case of doubt the OpenSC
LGPL license should count, because they would not legally be allowed
to "remove" anything from the OpenSC license or else they would
forfeit their right to build upon OpenSC...
They contradict, but not in extremely fundamental ways. OpenSC is
LGPL, so they are allowed to mix OpenSC and their own code, and
license the resulting binary under nearly any license. So it is not
like GPL, where they would have to give the source code of the whole
library, etc. Additionally to not providing the .o files as I already
mentioned:
- They have to allow some kinds of reverse-engineering, though, which
they failed to (sufficiently) do.
- They have to allow modifications for "one's own use", they don't.
I don't need to rely on that bit of the LGPL anyway, as what I did is
covered under article 5, paragraph 3 of Directive 2009/24/EC of the
European Parliament and of the Council of 23 April 2009 on the legal
protection of computer programs.
It seems relatively clear to me that they intend their EULA to apply
to the finished product, and the LGPL is there to apply to the
OpenSC-derived parts, and those *only*. So the LGPL does not take
precedence over the whole.
What about taking precedence in the restricted meaning that what the
LGPL *does* require over the whole (allow modifications for one's own
use, allow some reverse-engineering, ...) is actually granted to us
automatically? For this, I'll refer to
http://www.maitre-eolas.fr/post/2010/12/26/Lrsquo%3Baffaire-ldquo%3Bla-cart…
where Maître Eolas argues that it does not. He says that only the
copyright holders of OpenSC have standing to act against Gemalto's
LGPL violation, and still then not by simply taking the liberties
required by the LGPL over the binary-only parts. Only by requiring
Gemalto to cease and desist distributing libgemsafe, or get
compensation from them, or ...
As far as the java JNI "shim" that loads the
original gemsafe lib by
absolute path is concerned, maybe this could be tricked by renaming
the open source driver? Theoretically, the JNI shim should only
depend on PKCS11 standard APIs, so this might work...
I think I tried that, but it failed. I didn't try very hard, though.
From what they explained to me, they did this because
the Java
Crypto API (not the C PKCS11 API) was lacking some features which
they "needed" (such as chosing among more than one card that might
be present), so they had to resort to this "hack" if they wanted to
offer these features from Java.
They could have avoided Java altogether ;-)
--
Lionel