While this news is indeed dire and very disturbing; one should emphasise that it is about pre-configured/initialized SIM cards for telephony.
These use a single shared secret (i.e. the card contains a secret value (known as the Ki) - which is also known to the phone company).
These are generated and programmed in the factory into batches of card; and then a copy of all cards in a batch is sent to the telephone company on cdrom, by FTP or email. All this is supposedly done in a secure environment; which we now know was breached.
This is quite *unlike* the dominant use in OpenSC land; where we take a blank card and either:
1) generate the random bits and keys *on* the card; and export just the public key.
With the secret key never leaving the card.
2) generate those in our ‘own’ (hopefully secure) environment and then burn them into the card.
which is fundamentally a different thing.
However - especially for those doing ‘2’ on a large scale - studying how Gemalto was breached may be educational; as you would not want to suffer the same fate.
This attack does illustrate though how valuable it is to have a public/private key pair; with the private key generated within the secure enclave of the chipcard. So that ‘no one’ involved knows it. Hopefully this will help sway a lot of enterprises away from path ‘2’ (because of cost and convenience concerns) and onto ‘1’. And it will certainly give (large) organisations that have outsourced this sort of initialisation some pause.
The market for something like OpenSC with something like EJBCA with some decent UI for mass issuance of chipcards ‘in house’ has perhaps grown a wee little :).
Il 20/02/2015 13:16, Dirk-Willem van Gulik ha scritto:
> 1) generate the random bits and keys *on* the card; and export just the public key.
Too bad that this way if your card gets damaged you lose your keys and
there's no way to recover 'em.
That leaves only option
> 2) generate those in our ‘own’ (hopefully secure) environment and then burn them into the card.
BUT IIRC SmartcardHSM offers "controlled export" of keys.
that is the same question I asked myself this morning. And to be honest:
I don't know for sure - it's possible, although not likely.
We take this as a wake-up call to review our internal procedures and
look were we can tighten security even further.
What is probably our advantage over Gemalto, is that we are just a three
people company, located in the basement of my own house. And I know and
trust my colleagues and have worked with them for over a decade now.
We rely on JCOP cards supplied by NXP and of course we have no other
option than to trust NXP (and the evaluator that did CC) for not having
build any backdoors into the product.
For the part of the product were we take responsibility (Applet,
production, PKI) we follow a very formal development, test and release
process (we are still looking to get a CC certificate at some point in
time - the formal process is a CC requirement).
We have a full set of formal requirements that can be traced in the code
and test framework. This ensures 100% test coverage for the code - there
is no functionality in the code that doesn't have a formal requirement
and as such a validating test.
The code is build on a dedicated build-server after sign-off in a git
repository. Builds are reproducible and the resulting .cap file is
released only to production after it passed all regression tests. In
production it's stored in the production revision control system.
During production of the SmartCard-HSM we take un-initialized JCOP cards
and load the applet code from scratch into the device. After generating
the device authentication key internally, the device certificate is
issued by the production PKI and the SmartCard-HSM is irreversibly set
to life-cycle state SECURED. The production PKI uses a SmartCard-HSM to
safeguard signing keys. The root CA is an offline CA with dual-control,
normally locked away.
There are very few steps where this process could be compromised, as
most steps require manual intervention by the three of us.
> A more disturbing info I just found is that Java/BASIC cards have been
> placed way down in the security list by Sergei Skorobogatov in
> http://www.cl.cam.ac.uk/~sps32/SG_talk_SRB.pdf I'd really be interested how this must be read.
> Hope those are not the "certified" cards. BTW who thinks there could be
> backdoors in cards is quite right...
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________
> Opensc-devel mailing list
> [hidden email] > https://lists.sourceforge.net/lists/listinfo/opensc-devel >