Re: [opensc-devel] New SE (Security Element) Company Formed
On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... Interenet as an ideal is one thing, business as usual must still live on, unfortunately. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
2012/11/21 Martin Paljak mar...@martinpaljak.net: On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... are you sure that is still the case? SMS flat is down to 5€/month over here. and I use google talk all the time instead of SMS, unless it is someone who doesn't have an android phone. Interenet as an ideal is one thing, business as usual must still live on, unfortunately. thats a bit harsh I think - its not like the mobile carriers e.g. aren't trying to sell payment systems on top of their infrastructure or similar, but at the end it doesn't gain wide acceptance it seems. maybe too expensive? also for them change is very expensive - their equipment is certified and expensive, and any additional feature might require an upgrade to new equipment with expensive addons in the software/hardware. plus they have a huge amount of equipment so any change affects a lot of parts. no wonder the mobile carriers think change is expensive. still they change when necessary, e.g. to adapt to new speeds/tech like LTE, but in that case they know that everyone left behind will likely die soon, and that the quality level on their network will only get worse with the explosion of mobile data usage. I cannot comment on many things discussed here, but as someone living in an SSO world, where I have one place to authenticate, and every app I use gets the authentication from that central place via OAuth: that is real nice. Thus my personal goal would be no longer to be able to get many credentials from many places, but only to handle one credentials with one service on the other side, and handle that very, very well. every other place can use OAuth with that central place. (remember how I opposed using openid in the past? seeing how nice it is to have such infrastructure changed my view on that) Regards, Andreas Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: 2012/11/21 Martin Paljak mar...@martinpaljak.net: On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... are you sure that is still the case? SMS flat is down to 5€/month over here. and I use google talk all the time instead of SMS, unless it is someone who doesn't have an android phone. Even public sources estimate a nice business And text messaging is still a big business, accounting for an estimated $21 billion in U.S. revenue for telecom companies last year and an estimated $23 billion this year, according to the Consumer Federation of America. Source: http://articles.latimes.com/2011/aug/21/business/la-fi-texting-20110822 The ROI on SMS is not comparable to the investments and increasing traffic for data services (where messaging is accounts only for a 1% of traffic, I believe) Interenet as an ideal is one thing, business as usual must still live on, unfortunately. thats a bit harsh I think - its not like the mobile carriers e.g. aren't trying to sell payment systems on top of their infrastructure or similar, but at the end it doesn't gain wide acceptance it seems. maybe too expensive? Sure, as long as they can get a % of the business happening in their walled garden. Then again, financial services and payments are important parts of the overall who controls the money routes, controls the business play, so I don't expect any of the carriers or handset platform providers to open up a loophole that would allow for some 3rd party to easily take their market, without paying. There's just no commercial interest. So yes, harsh, but I believe realistic. I cannot comment on many things discussed here, but as someone living in an SSO world, where I have one place to authenticate, and every app I use gets the authentication from that central place via OAuth: that is real nice. Thus my personal goal would be no longer to be able to get many credentials from many places, but only to handle one credentials with one service on the other side, and handle that very, very well. every other place can use OAuth with that central place. (remember how I opposed using openid in the past? seeing how nice it is to have such infrastructure changed my view on that) Sure. But that should be an *option* rather than requirement. Eventually you still would want to separate your bank account from your google account, for example. Maybe in 10 years this sounds like a stupid idea for the younger generation, but this moment in time I still would prefer the option to choose my credentials and identities (but would love to re-use them as *I* want, not how some vendor wants it (what makes OpenID better than peered implementations like saml or facebook connect or..) Sorry to hear about the OpenID thing though ;) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
2012/11/21 Martin Paljak mar...@martinpaljak.net: On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: 2012/11/21 Martin Paljak mar...@martinpaljak.net: On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... are you sure that is still the case? SMS flat is down to 5€/month over here. and I use google talk all the time instead of SMS, unless it is someone who doesn't have an android phone. Even public sources estimate a nice business And text messaging is still a big business, accounting for an estimated $21 billion in U.S. revenue for telecom companies last year and an estimated $23 billion this year, according to the Consumer Federation of America. Source: http://articles.latimes.com/2011/aug/21/business/la-fi-texting-20110822 http://ovum.com/press_releases/ovum-estimates-that-operators-lost-13-9bn-in-2011-due-to-social-messaging/ other source wine about lost revenue due to people using facebook chat and friends instead of sms. (no statement relating to increased revenue for the data tarif so people can use facebook of course...) The ROI on SMS is not comparable to the investments and increasing traffic for data services (where messaging is accounts only for a 1% of traffic, I believe) yes, the stories about price per bit for a sms are quite old. but if 2011 already 9% of chat moved from sms to facebookfriends, that is a strong development and guess that trend increases. Interenet as an ideal is one thing, business as usual must still live on, unfortunately. thats a bit harsh I think - its not like the mobile carriers e.g. aren't trying to sell payment systems on top of their infrastructure or similar, but at the end it doesn't gain wide acceptance it seems. maybe too expensive? Sure, as long as they can get a % of the business happening in their walled garden. Then again, financial services and payments are important parts of the overall who controls the money routes, controls the business play, so I don't expect any of the carriers or handset platform providers to open up a loophole that would allow for some 3rd party to easily take their market, without paying. There's just no commercial interest. So yes, harsh, but I believe realistic. I cannot comment on many things discussed here, but as someone living in an SSO world, where I have one place to authenticate, and every app I use gets the authentication from that central place via OAuth: that is real nice. Thus my personal goal would be no longer to be able to get many credentials from many places, but only to handle one credentials with one service on the other side, and handle that very, very well. every other place can use OAuth with that central place. (remember how I opposed using openid in the past? seeing how nice it is to have such infrastructure changed my view on that) Sure. But that should be an *option* rather than requirement. Eventually you still would want to separate your bank account from your google account, for example. Sure, I want several different authentication options, one for work, one for home, but causal things, and one for very important things like banking. but if I have accounts at several banks, all could use a shared very-secure authentication mechanism, I wouldn't mind. the problem is each bank wants to have their own mechanism I guess. how is the experience with the eID in estonia? I thought that was the one case where people used one central eID card for many things, like authenticating to banks for online banking - and it is not tied to one bank only? Maybe in 10 years this sounds like a stupid idea for the younger generation, but this moment in time I still would prefer the option to choose my credentials and identities (but would love to re-use them as *I* want, not how some vendor wants it (what makes OpenID better than peered implementations like saml or facebook connect or..) I love the idea of having more control. if there is a secure clearing provider for authentication, I might prefer to have him in the loop, rather than the bank. some of them don't seem to do a good job with basic things like a useable web page, or asking me for strangely limited passwords, etc. I'm not advocating the one for
Re: [opensc-devel] New SE (Security Element) Company Formed
Hi Peter, http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. we are currently looking for a secure keystore on an android phone. Anything 'half bad' is better than nothing ;-) Do you got any alternatives? Greetings, Andreas -- Andreas Kühne phone: +49 177 293 24 97 mailto: kue...@trustable.de Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868 Directors Andreas Kühne, Heiko Veit Company UK Company No: 5218868 Registered in England and Wales ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
On 11/15/2012 3:40 AM, Andreas Kuehne wrote: Hi Peter, http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. we are currently looking for a secure keystore on an android phone. Anything 'half bad' is better than nothing ;-) Do you got any alternatives? http://code.google.com/p/seek-for-android/ Says it can use a crypto chip on a microSD card. http://www.apriva.com/products/iss/authentication/reader http://www.apriva.com/sites/default/files/android_sdk.pdf Bluetooth reader and Android SDK http://www.biometricassociates.com/products-baimobile/smart-card-reader-iphone-android.html Greetings, Andreas -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
On 2012-11-15 08:56, Andreas Schwier wrote: Does the API matter anyway ? No, it's the functionality the TEE provides: Generate, store, maintain and use cryptographic material and do all kinds of risk management. And these functions do not really require web service and overloaded APIs. They require APIs that are consistent, simple to implement and simple to be security evaluated. An ISO 7816-4 API is not an elegant API, but is has been around for a long time, people understand it and it does what it is supposed to do. There's a fly in the soup. The smart card industry haven't after all these years been able establishing an enrollment system for the web. I.e. there is nothing to build on really so we might as well start from scratch. Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. Anders I would love to see a CC certified TEE that has an embedded JavaCard VM with lots of memory and sufficient processing power. Andreas Am 15.11.2012 00:13, schrieb Peter Stuge: Anders Rundgren wrote: http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
Anders Rundgren wrote: http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
Does the API matter anyway ? No, it's the functionality the TEE provides: Generate, store, maintain and use cryptographic material and do all kinds of risk management. And these functions do not really require web service and overloaded APIs. They require APIs that are consistent, simple to implement and simple to be security evaluated. An ISO 7816-4 API is not an elegant API, but is has been around for a long time, people understand it and it does what it is supposed to do. I would love to see a CC certified TEE that has an embedded JavaCard VM with lots of memory and sufficient processing power. Andreas Am 15.11.2012 00:13, schrieb Peter Stuge: Anders Rundgren wrote: http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
