Good points, Jean-Luc. Open source is not about free software, as
Rich Stallman has noted repeatedly. Nor is it about easily modified
software. It is about understandable and therefore trustworthy software.
I wonder how many smart card manufacturers would be willing
to give their source code to any government that requested it as
Microsoft is doing with their source code.
I don't doubt that smart card manufactures at one time possessed
special expertise in countering environmental attacks. Whether this
understanding was effectively implemented in the software in the smart
card is another question. I have no evidence here. I have seen a card
that burped up its keys when given valid sequences of commands so
the trip from expertise to implementation does deserve attention.
Furthermore, it must be noted that the half-life of physical attack
expertise is about two years so a relevant question is how quickly
can the manufactureres respond. In the case of both timing and power
attacks, the chip manufacturers responded much more quickly
and more effectively than the smart card manufacturers.
Which brings another point. Hasn't the physical security of the token
moved by and large from software to hardware? It the early days
of smart cards, the card software did have to worry about these things.
But aren't those days long gone and isn't the expertise that created
this software obsolete? As far as today's environmental attacks go,
the expertise is with the chip manufactureres and the counter measures
are largely in the silicon, not in the software.
IMHO, as always.
Cheers, Scott
-----Original Message-----
From: Jean-Luc Giraud [mailto:[EMAIL PROTECTED]
Sent: Sun 8/17/2003 9:41 PM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [Muscle] Re: SSP smart card
On Saturday, August 16, 2003, at 01:07 AM, Scott Guthery wrote:
> Interesting discussion.
>
> Conjecture I: Smart card software has more in common with cryptographic
> algorithms than with computer operating systems.
>
> None of us (I assume) would use a cryptographic algorithm without
> being provided
> every technical detail of the algorithm and assurance that the
> realization
> we planned to use faithfully implemented these details. Cryptographic
> security
> flows from key secrecy, not algorithm secrecy.
I agree that the security relies on key secrecy and not the algorithm
secrecy.
IMHO there is also another thing to take into account: the algorithm
and the keys are used on a physical piece of hardware (like a smart
card). This piece of hardware is likely to leak key material even if
the software "faithfully implements the details" of the algorithm. In
order to build a secure system, a functionally accurate software
implementation is necessary but not sufficient. A secure implementation
(against side-channel attacks or other forms of attacks) is required.
Writing of secure implementation of an algorithm is very time-consuming
and requires a lot of expertise. Smart card manufacturers usually have
this expertise.
> There is a long history of smart card manufacturers and smart card
> issuers
> embedding backdoors in smart card software. Witness the weak
> algorithms
> and keys in GSM SIMs and http://www.parodie.com/humpich/home.htm/
I find this affirmation quite aggressive against the smart card
industry. The 2 examples you give (GSM and Humpich) are certainly not
the fault of the card manufacturers (who faithfully implemented the
specifications and any code review would have said so). The issue was a
problem of closed specifications that were not widely reviewed. These
specifications had security issues.
I have worked as a smart card OS developer and I never put any backdoor
in the OSes I wrote. I have never heard of anybody having been asked to
do it (let alone actually doing it!!). I have always treated the
existence of back doors in a smart card OS as an urban legend. If in
your long involvement in card OS design you have come across such back
doors and are allowed to mention them, I'd be very interested in some
examples.
Frankly, if I had to break a system using a card, I would focus more on
the card environment than the card itself. If I could not corrupt the
environment and had the means to get a trapdoor installed somewhere I
would put it on the chip. This would let me break any OS running on
that chip. However I am quite sure that Secure IC manufacturer do not
do this.
> Conjecture II: If you as a card issuer or cardholder can't analyze the
> source
> code of the smart card operating system in your card and insure that
> what is
> in the card you hold is exactly the code you have analyzed, you are
> playing
> at security.
This does not protect you from an extra "feature" in the hardware that
could bypass the OS you have reviewed (see above).
Please do not get me wrong: I am for open specifications and open
source systems. Software I write in my spare time is open source under
a BSD license. I personally wish that the industry had a more open
attitude. This is why I try to help Muscle and the Musclecard
technology.
Cheers,
JLuc.
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle
