New SE (Security Element) Company Formed

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

New SE (Security Element) Company Formed

Anders Rundgren
http://www.theregister.co.uk/2012/11/13/trustzone_company

Smart cards?  Don't think so.

Anders
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Peter Stuge-4
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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Andreas Schwier
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
> [hidden email]
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

akuehne
In reply to this post by Peter Stuge-4
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: [hidden email]

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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Douglas E. Engert


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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Anders Rundgren
In reply to this post by Andreas Schwier
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
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Martin Paljak-4
On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren
<[hidden email]> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Andreas Jellinghaus-4
2012/11/21 Martin Paljak <[hidden email]>:

> On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren
> <[hidden email]> 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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Martin Paljak-4
On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus
<[hidden email]> wrote:

> 2012/11/21 Martin Paljak <[hidden email]>:
>> On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren
>> <[hidden email]> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New SE (Security Element) Company Formed

Andreas Jellinghaus-4
2012/11/21 Martin Paljak <[hidden email]>:

> On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus
> <[hidden email]> wrote:
>> 2012/11/21 Martin Paljak <[hidden email]>:
>>> On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren
>>> <[hidden email]> 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 facebook&friends, 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 everything", but rather the option of
having some hub in the middle. e.g. if you want to buy something, do
you prefer to create a account at some new webstore, do you prefer to
have a middle man for everything but shipping of the good (e.g. amazon
marketplace, ebay buying at fixed price. ...) or a mix of that vendors
web-.page, but the account tied to your google / facebook / ....
account?

my favorite is not opening an account at a webstore - but very few
webstores offer to buy without opening an account.
my least favorite option an account on their page - very likely they
will both and some hacker extracts all data.
so using amazon.com or ebay as middle man can help, or only create an
account connected to my google apps account,
so I don't need to enter/remember some password.

Andreas

>
> Sorry to hear about the OpenID  thing though ;)
>
> Martin
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel