Re: [opensc-devel] OpenSC's future relevance
Anders Rundgren wrote: It is about a 50 cent built-in TPM versus $200+ of highly inconvenient c**p that unlikely will ever be directly supported by the mobile platforms vendors. There is still room to maneuver here. Smartcards with smartphones are an utter PITA and all the users (esp. leadership, since they're the ones with the smartphones) know it. There's an opportunity to shift thinking into smartphone-as-credential *if* an appropriate level of key protection can be shown. Quite challenging, isn't it? Adoption of anything is always this way. It's an uphill battle until the tipping point is reached. -- Tim smime.p7s Description: S/MIME Cryptographic Signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC's future relevance
Tim, I would love discussing the details but unfortunately the USG and their suppliers is in such a mess that I don't think it would be constructive: http://www.trustdigital.com/downloads/TD_EMM_CAC_Pack_101008.pdf It is about a 50 cent built-in TPM versus $200+ of highly inconvenient c**p that unlikely will ever be directly supported by the mobile platforms vendors. Anyway, *my* ambition is making 2FA (Two Factor Authentication) as simple and cost-efficient as is possible. Adding security-hardened silicon is something that will come automatically when (if actually...) the need demand/usage increases. My former US colleges tell me that US consumers will never use devices for authentication on the Internet. Given the *current* devices I think they are right refusing. Quite challenging, isn't it? Anders - Original Message - From: "Timothy J. Miller" To: "Anders Rundgren" Cc: "Alon Bar-Lev" ; Sent: Tuesday, May 05, 2009 22:51 Subject: Re: [opensc-devel] OpenSC's future relevance Anders Rundgren wrote: > Conclusion: the smart card industry is working with dated designs > that doesn't really scale. The smartcard industry knows where the money is, and it's not in selling cards. > Tim: private keys are protected by a master key residing in EEPROM > in the USB controller. That's fine for *storage.* Storage is only *one* place where key exposure is a concern. Where's the key when it's being used? Are you using the USB controller as a crypto engine? -- Tim ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BUG compiling with --disable-openssl
2009/5/6 Aktiv Co. Aleksey Samsonov : > Hi! > > cardos-tool.c: In function 'cardos_format': > cardos-tool.c:621: error: label 'erase_state' used but not defined > > cardos-tool.c:779: > #ifdef ENABLE_OPENSSL > ... > erase_state: > > Thanks Corrected in revision 3687. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC's future relevance
Anders Rundgren wrote: > I plan to implement such an API in consumer-grade USB memory > sticks. I do hardware as well, in Malmö though, but maybe we could talk. > P15 - Does not add value (except for consultants...) > 7816 and file systems - Ridiculous > Serial t0/t1 communication - Obsolete > Active card-readers - Why? > P11 - 10% is OK, the rest is rubbish I agree. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] BUG compiling with --disable-openssl
Hi! cardos-tool.c: In function 'cardos_format': cardos-tool.c:621: error: label 'erase_state' used but not defined cardos-tool.c:779: #ifdef ENABLE_OPENSSL ... erase_state: Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC's future relevance
Am Dienstag 05 Mai 2009 21:26:50 schrieb Anders Rundgren: > Using a PKI API scheme you don't need to abstract anything or depend > on 400 pages P11 specs full with optional features making smart cards for > consumers a really messy story. It's about time ending this craze. > > P15 - Does not add value (except for consultants...) > 7816 and file systems - Ridiculous > Serial t0/t1 communication - Obsolete > Active card-readers - Why? > P11 - 10% is OK, the rest is rubbish I agree, what we have is a very old design, noone would do it like this again these days. Also in general it didn't work out. > For PKI support you only need a rather tiny API. what kind of API? I still think the microsoft approach is the right direction - a high level API good enough, so that applications can be switched from filesystem based certificates to "smart card" based certificates etc. without changes to the application. (at least if the app writer didn't prevent that...). > I plan to implement such an API in consumer-grade USB memory sticks. why memory sticks? some people want to use smart cards, but insist on readers with display and pinpad for security reasons. I think the evolution might take us to pda/smart phone/similar devices - a device you already have and carry around with you, and you trust. (of course mobile phones aren't really secure right now, but I think software stacks like android have the right concepts to build on at least). I rather wonder: what would be the best way to relay the need for signing and decryption to the secure device? bluetooth, usb, wlan? what protocol? and only use a stupid protocol like "sign this hash", or wouldn't it be much better to forward the whole document (e.g.for a pdf signing), or also control other parameters (e.g. ssl session details, so the "none" cipher is not allowed, and the "secure device" can check the ssl server cert too)? I'm worried that - at least with linux - each app seams to have the same basics: ssl settings, crypto settings, list of root certificates and so on. that is a bad design from my point of view, you should not need to configure the same setting in many different places (e.g. turn off md5 if you want that). also for other protocols like ssh I think it would be nice to have security information (e.g. known_hosts file) on the security device too, so that information is shared between computers. having that information on each machine I use without a sync isn't so great. what do you think? what is the direction that secure authentication with a device should take? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
