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
