Wait a second - you can not simply hide a backdoor in a Common Criteria evaluated operating system. There are too many entities that would need to be involved in the process: The manufacturer, the evaluator, the certification body and possibly a national regulator (Here for example NXP, TÜV-IT, BSI and Bundesnetzagentur).
And if there were a backdoor, then the manufacturer could be held liable if the backdoor was exploited. They wouldn't risk their business just to comply with a fairly small US smart card market requirement. Btw. we are working on a solution to add OpenPGP support for our SmartCard-HSM, which is running on a JCOP platform. It's available as card, USB-Stick or MicroSD card. Andreas Am 02.12.2013 19:33, schrieb Peter Lebbing: > On 02/12/13 15:24, NdK wrote: >> Who can you really trust? If you don't trust NXP, then you can't use any >> of their JCOP chips... What would stop 'em from adding an undocumented >> command to the card manager that dumps the whole memory? > > Exactly the point I was going to make when I read your mail up to this point. > > And don't forget that the draconian US laws aren't just for multinationals > whose > main offices are in the US... it's also for multinationals with any office in > the US. I wouldn't count on it that NXP thought "we'd rather lose the US > market > than backdoor our smartcards". > > Since smartcards are primarily used for security purposes, I wouldn't be > surprised if it responded specially to a message signed by the NSA (or > encrypted > with a symmetric cipher with a specific key known to the NSA). > >> Only BasicCard supports longer keys, but I'm not using Basic >> since Commodore-64 era :) > > I agree with you, but programs on BasicCards are generally rather simple since > they just define the contents for the ISO 7816 APDU's and files, and > everything > else, including the file system on the card, is part of the interpreter and OS > on the card. And BASIC has two advantages: it's easy to learn, and it's easy > to > compile to bytecode (that is, writing a compiler is easy). > > Obviously, the design of the language from an academic standpoint is really > bad > by todays standards; we learned a lot since BASIC was designed. But that's not > so important for the small applet-like programs that only work with the > contents > of ISO 7816 APDU's and files. > > Peter. > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users