Smart Cards vs. TEEs

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

Smart Cards vs. TEEs

Anders Rundgren-2
Follow-up on the TPM is dead posting...

It doesn't matter if hell freezes over, Smart Cards will never be able to do this:
https://play.google.com/store/apps/details?id=org.webpki.mobile.android

If you don't have an Android device (or 5-10 minutes to spend...), here is a short description:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run

The idea is that the scheme should be a part of a standard phone.
Keys would be protected by a TEE and hopefully by a Security Enclave as well.

Anders

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Andreas Schwier (ML)
Hi Anders,

why do you think that Smart Cards will never be able to do that ?

The SmartCard-HSM is functionality-wise doing exactly the same [1] and
FIDO has a similar scheme for key attestation.

What I don't understand in your proposal, is where the attestation key
comes from ? Who provides the initial trust that the key device at the
client can be trusted ?

Andreas

[1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf

On 07/14/2014 11:10 AM, Anders Rundgren wrote:

> Follow-up on the TPM is dead posting...
>
> It doesn't matter if hell freezes over, Smart Cards will never be able to do this:
> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>
> If you don't have an Android device (or 5-10 minutes to spend...), here is a short description:
> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>
> The idea is that the scheme should be a part of a standard phone.
> Keys would be protected by a TEE and hopefully by a Security Enclave as well.
>
> Anders
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck®
> Code Sight™ - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Anders Rundgren-2
On 2014-07-14 11:28, Andreas Schwier wrote:
> Hi Anders,
>
> why do you think that Smart Cards will never be able to do that ?

Because the smart card industry have no connections with the browser vendors, never had.

>
> The SmartCard-HSM is functionality-wise doing exactly the same [1] and

Would you say that this is consumer solution?


> FIDO has a similar scheme for key attestation.

FIDO does not support PKI.

>
> What I don't understand in your proposal, is where the attestation key
> comes from ? Who provides the initial trust that the key device at the
> client can be trusted ?

Inside of the TEE.  AIFAIK, Apple already have an attestation key there.

Anders

>
> Andreas
>
> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>
> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>> Follow-up on the TPM is dead posting...
>>
>> It doesn't matter if hell freezes over, Smart Cards will never be able to do this:
>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>
>> If you don't have an Android device (or 5-10 minutes to spend...), here is a short description:
>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>
>> The idea is that the scheme should be a part of a standard phone.
>> Keys would be protected by a TEE and hopefully by a Security Enclave as well.
>>
>> Anders
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck®
>> Code Sight™ - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck®
> Code Sight™ - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Andreas Schwier (ML)
On 07/14/2014 11:33 AM, Anders Rundgren wrote:
> On 2014-07-14 11:28, Andreas Schwier wrote:
>> Hi Anders,
>>
>> why do you think that Smart Cards will never be able to do that ?
>
> Because the smart card industry have no connections with the browser
> vendors, never had.
Maybe I don't understand what key provisioning has to do with the
browser. IMHO it has to do with a RA process that identifies the
applicant, establishes a link between the public key and identification
data and issues a certificate. PKCS#10 already does a good job, it's
just missing the assurance of a secure and identified key store - in
case as a CA you want to make sure the key exists only once and you want
to know where. If as a CA you don't care, then proof-of-possession for
the private key is sufficient.
>
>>
>> The SmartCard-HSM is functionality-wise doing exactly the same [1] and
>
> Would you say that this is consumer solution?
Absolutely. Like the physical keys on my key ring, I want a device for
my cryptographic key that I can put in my pocket. If I need the key, I
plug that device into a PC or hold it to the NFC reader in my mobile and
perform the crypto operation. I don't leave the keys in the lock.

Like I have an USB-Stick for my data, I have an USB-Stick for my keys.
>
>
>> FIDO has a similar scheme for key attestation.
>
> FIDO does not support PKI.
That's one of the FIDO shortcomings. It only sorts out the problem of
authentication, but I also want to securely store my keys to sign
documents or decrypt data. FIDO is not a universal key store - but a
universal key store is what makes sense IMHO.
>
>>
>> What I don't understand in your proposal, is where the attestation key
>> comes from ? Who provides the initial trust that the key device at the
>> client can be trusted ?
>
> Inside of the TEE.  AIFAIK, Apple already have an attestation key there.
And how does the CA establish initial trust in the Apple attestation key
? I've never seen such a key and I doubt that Apple will provide any
assurance to a third party regarding such a key.

You need a better scheme if you want key attestation.

>
> Anders
>
>>
>> Andreas
>>
>> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>>
>> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>>> Follow-up on the TPM is dead posting...
>>>
>>> It doesn't matter if hell freezes over, Smart Cards will never be
>>> able to do this:
>>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>>
>>> If you don't have an Android device (or 5-10 minutes to spend...),
>>> here is a short description:
>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>>
>>>
>>> The idea is that the scheme should be a part of a standard phone.
>>> Keys would be protected by a TEE and hopefully by a Security Enclave
>>> as well.
>>>
>>> Anders
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>> Code Sight™ - the same software that powers the world's largest
>>> code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck®
>> Code Sight™ - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Anders Rundgren-2
On 2014-07-14 12:07, Andreas Schwier wrote:
> On 07/14/2014 11:33 AM, Anders Rundgren wrote:
>> On 2014-07-14 11:28, Andreas Schwier wrote:
>>> Hi Anders,
>>>
>>> why do you think that Smart Cards will never be able to do that ?
>>
>> Because the smart card industry have no connections with the browser
>> vendors, never had.

DISCLAIMER:
The thing I described is my take on the subject, there is nothing
that says that my take will prevail.  But I believe that something along
these line will.



> Maybe I don't understand what key provisioning has to do with the browser.

If we are talking consumers, they interact with services with the browser.
Services may provide keys through the very same "universal interface".
This is the use-case for the stuff I'm working on.


> IMHO it has to do with a RA process that identifies the
> applicant, establishes a link between the public key and identification
> data and issues a certificate. PKCS#10 already does a good job, it's
> just missing the assurance of a secure and identified key store - in
> case as a CA you want to make sure the key exists only once and you want
> to know where. If as a CA you don't care, then proof-of-possession for
> the private key is sufficient.

This process is not standardized and none of the browser-based enrollment
systems out there (MSIE, Firefox, Chrome) even deal with PIN-codes.
For smart cards you usually have to initialize the key entry locally
using some proprietary SW.

The US government had their chance when they defined PIV but they never
thought outside of the federal-government-box and that was [probably]
the last shot the smart card industry got on creating an Internet-ready
PKI-card.


>>>
>>> The SmartCard-HSM is functionality-wise doing exactly the same [1] and
>>
>> Would you say that this is consumer solution?
> Absolutely. Like the physical keys on my key ring, I want a device for
> my cryptographic key that I can put in my pocket. If I need the key, I
> plug that device into a PC or hold it to the NFC reader in my mobile and
> perform the crypto operation. I don't leave the keys in the lock.
>
> Like I have an USB-Stick for my data, I have an USB-Stick for my keys.

I was referring to the initialization of it OTA.

>>
>>
>>> FIDO has a similar scheme for key attestation.
>>
>> FIDO does not support PKI.
> That's one of the FIDO shortcomings. It only sorts out the problem of
> authentication, but I also want to securely store my keys to sign
> documents or decrypt data. FIDO is not a universal key store - but a
> universal key store is what makes sense IMHO.

Yes, this is the core of my line of work.

>>
>>>
>>> What I don't understand in your proposal, is where the attestation key
>>> comes from ? Who provides the initial trust that the key device at the
>>> client can be trusted ?
>>
>> Inside of the TEE.  AIFAIK, Apple already have an attestation key there.
> And how does the CA establish initial trust in the Apple attestation key
> ? I've never seen such a key and I doubt that Apple will provide any
> assurance to a third party regarding such a key.
>
> You need a better scheme if you want key attestation.

FWIW, that's probably all that you can get.  I'm sure that such
a key will contain the usual BS like "NOT FIT FOR ANY PURPOSE ETC"
which US legislation requires :-)

Anders

>>
>> Anders
>>
>>>
>>> Andreas
>>>
>>> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>>>
>>> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>>>> Follow-up on the TPM is dead posting...
>>>>
>>>> It doesn't matter if hell freezes over, Smart Cards will never be
>>>> able to do this:
>>>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>>>
>>>> If you don't have an Android device (or 5-10 minutes to spend...),
>>>> here is a short description:
>>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>>>
>>>>
>>>> The idea is that the scheme should be a part of a standard phone.
>>>> Keys would be protected by a TEE and hopefully by a Security Enclave
>>>> as well.
>>>>
>>>> Anders
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>>> Code Sight™ - the same software that powers the world's largest
>>>> code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>> Code Sight™ - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Andreas Schwier (ML)
OTA is the right keyword in your post: OTA works end-to-end between the
OTA server and the SIM. It ensures trusted communication between the
device and the CA. The CA knows the keys are from a genuine device
provided and managed by the MNO.

So device management here has nothing to do with the browser process for
enrolment.

You could even have a secure key store deployed anywhere remote and do
provisioning from a central key management system - the core principle
remains the same: Trusted communication between the device and the
managing entity.

Putting that into a browser without the link to the key storing device
is nothing better than the current KEYGEN protocol in Firefox and alike.

That's why we split things: There is a provisioning layer using
RAMOverHTTP that establishes a trusted link between the device and the
server and this layer is activated from within the web application.
However, the provisioning layer also works independent of the browser in
rich clients or just as a shell script on a remote machine.

And yes, RAMOverHTTP works on an APDU level, because that is the natural
communication mechanism that reaches all the way into the device.

On 07/14/2014 12:27 PM, Anders Rundgren wrote:

> On 2014-07-14 12:07, Andreas Schwier wrote:
>> On 07/14/2014 11:33 AM, Anders Rundgren wrote:
>>> On 2014-07-14 11:28, Andreas Schwier wrote:
>>>> Hi Anders,
>>>>
>>>> why do you think that Smart Cards will never be able to do that ?
>>>
>>> Because the smart card industry have no connections with the browser
>>> vendors, never had.
>
> DISCLAIMER:
> The thing I described is my take on the subject, there is nothing
> that says that my take will prevail.  But I believe that something along
> these line will.
>
>
>
>> Maybe I don't understand what key provisioning has to do with the
>> browser.
>
> If we are talking consumers, they interact with services with the browser.
> Services may provide keys through the very same "universal interface".
> This is the use-case for the stuff I'm working on.
>
>
>> IMHO it has to do with a RA process that identifies the
>> applicant, establishes a link between the public key and identification
>> data and issues a certificate. PKCS#10 already does a good job, it's
>> just missing the assurance of a secure and identified key store - in
>> case as a CA you want to make sure the key exists only once and you want
>> to know where. If as a CA you don't care, then proof-of-possession for
>> the private key is sufficient.
>
> This process is not standardized and none of the browser-based enrollment
> systems out there (MSIE, Firefox, Chrome) even deal with PIN-codes.
> For smart cards you usually have to initialize the key entry locally
> using some proprietary SW.
>
> The US government had their chance when they defined PIV but they never
> thought outside of the federal-government-box and that was [probably]
> the last shot the smart card industry got on creating an Internet-ready
> PKI-card.
>
>
>>>>
>>>> The SmartCard-HSM is functionality-wise doing exactly the same [1] and
>>>
>>> Would you say that this is consumer solution?
>> Absolutely. Like the physical keys on my key ring, I want a device for
>> my cryptographic key that I can put in my pocket. If I need the key, I
>> plug that device into a PC or hold it to the NFC reader in my mobile and
>> perform the crypto operation. I don't leave the keys in the lock.
>>
>> Like I have an USB-Stick for my data, I have an USB-Stick for my keys.
>
> I was referring to the initialization of it OTA.
>
>>>
>>>
>>>> FIDO has a similar scheme for key attestation.
>>>
>>> FIDO does not support PKI.
>> That's one of the FIDO shortcomings. It only sorts out the problem of
>> authentication, but I also want to securely store my keys to sign
>> documents or decrypt data. FIDO is not a universal key store - but a
>> universal key store is what makes sense IMHO.
>
> Yes, this is the core of my line of work.
>
>>>
>>>>
>>>> What I don't understand in your proposal, is where the attestation key
>>>> comes from ? Who provides the initial trust that the key device at the
>>>> client can be trusted ?
>>>
>>> Inside of the TEE.  AIFAIK, Apple already have an attestation key there.
>> And how does the CA establish initial trust in the Apple attestation key
>> ? I've never seen such a key and I doubt that Apple will provide any
>> assurance to a third party regarding such a key.
>>
>> You need a better scheme if you want key attestation.
>
> FWIW, that's probably all that you can get.  I'm sure that such
> a key will contain the usual BS like "NOT FIT FOR ANY PURPOSE ETC"
> which US legislation requires :-)
>
> Anders
>
>>>
>>> Anders
>>>
>>>>
>>>> Andreas
>>>>
>>>> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>>>>
>>>> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>>>>> Follow-up on the TPM is dead posting...
>>>>>
>>>>> It doesn't matter if hell freezes over, Smart Cards will never be
>>>>> able to do this:
>>>>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>>>>
>>>>>
>>>>> If you don't have an Android device (or 5-10 minutes to spend...),
>>>>> here is a short description:
>>>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>>>>
>>>>>
>>>>>
>>>>> The idea is that the scheme should be a part of a standard phone.
>>>>> Keys would be protected by a TEE and hopefully by a Security Enclave
>>>>> as well.
>>>>>
>>>>> Anders
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Want fast and easy access to all the code in your enterprise? Index
>>>>> and
>>>>> search up to 200,000 lines of code with a free copy of Black
>>>>> Duck®
>>>>> Code Sight™ - the same software that powers the world's largest
>>>>> code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>>> Code Sight™ - the same software that powers the world's largest
>>>> code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Anders Rundgren-2
On 2014-07-14 12:46, Andreas Schwier wrote:
> OTA is the right keyword in your post: OTA works end-to-end between the
> OTA server and the SIM. It ensures trusted communication between the
> device and the CA. The CA knows the keys are from a genuine device
> provided and managed by the MNO.
>
> So device management here has nothing to do with the browser process for
> enrolment.

With OTA I only meant "the Mobile Internet".

>
> You could even have a secure key store deployed anywhere remote and do
> provisioning from a central key management system - the core principle
> remains the same: Trusted communication between the device and the
> managing entity.

This is what the described system claims to support.  The only difference
to your system is that the device doesn't care who the management entity is.

I.e. there are no predefined relations such as imposed by SCP02.

>
> Putting that into a browser without the link to the key storing device
> is nothing better than the current KEYGEN protocol in Firefox and alike.

SKS/KeyGen2 does a lot of things KEYGEN does not.  The security is as good
as the TEE can offer.  No more, no less.

If you try the PoC you can see the device bindings which also plays a role here.

>
> That's why we split things: There is a provisioning layer using
> RAMOverHTTP that establishes a trusted link between the device and the
> server and this layer is activated from within the web application.
> However, the provisioning layer also works independent of the browser in
> rich clients or just as a shell script on a remote machine.
>
> And yes, RAMOverHTTP works on an APDU level, because that is the natural
> communication mechanism that reaches all the way into the device.

That is what Gemalto thinks as well:
http://opoto.github.io/secure-element

The browser vendors do (AFAICT) not intend to support this work.

Anders

>
> On 07/14/2014 12:27 PM, Anders Rundgren wrote:
>> On 2014-07-14 12:07, Andreas Schwier wrote:
>>> On 07/14/2014 11:33 AM, Anders Rundgren wrote:
>>>> On 2014-07-14 11:28, Andreas Schwier wrote:
>>>>> Hi Anders,
>>>>>
>>>>> why do you think that Smart Cards will never be able to do that ?
>>>>
>>>> Because the smart card industry have no connections with the browser
>>>> vendors, never had.
>>
>> DISCLAIMER:
>> The thing I described is my take on the subject, there is nothing
>> that says that my take will prevail.  But I believe that something along
>> these line will.
>>
>>
>>
>>> Maybe I don't understand what key provisioning has to do with the
>>> browser.
>>
>> If we are talking consumers, they interact with services with the browser.
>> Services may provide keys through the very same "universal interface".
>> This is the use-case for the stuff I'm working on.
>>
>>
>>> IMHO it has to do with a RA process that identifies the
>>> applicant, establishes a link between the public key and identification
>>> data and issues a certificate. PKCS#10 already does a good job, it's
>>> just missing the assurance of a secure and identified key store - in
>>> case as a CA you want to make sure the key exists only once and you want
>>> to know where. If as a CA you don't care, then proof-of-possession for
>>> the private key is sufficient.
>>
>> This process is not standardized and none of the browser-based enrollment
>> systems out there (MSIE, Firefox, Chrome) even deal with PIN-codes.
>> For smart cards you usually have to initialize the key entry locally
>> using some proprietary SW.
>>
>> The US government had their chance when they defined PIV but they never
>> thought outside of the federal-government-box and that was [probably]
>> the last shot the smart card industry got on creating an Internet-ready
>> PKI-card.
>>
>>
>>>>>
>>>>> The SmartCard-HSM is functionality-wise doing exactly the same [1] and
>>>>
>>>> Would you say that this is consumer solution?
>>> Absolutely. Like the physical keys on my key ring, I want a device for
>>> my cryptographic key that I can put in my pocket. If I need the key, I
>>> plug that device into a PC or hold it to the NFC reader in my mobile and
>>> perform the crypto operation. I don't leave the keys in the lock.
>>>
>>> Like I have an USB-Stick for my data, I have an USB-Stick for my keys.
>>
>> I was referring to the initialization of it OTA.
>>
>>>>
>>>>
>>>>> FIDO has a similar scheme for key attestation.
>>>>
>>>> FIDO does not support PKI.
>>> That's one of the FIDO shortcomings. It only sorts out the problem of
>>> authentication, but I also want to securely store my keys to sign
>>> documents or decrypt data. FIDO is not a universal key store - but a
>>> universal key store is what makes sense IMHO.
>>
>> Yes, this is the core of my line of work.
>>
>>>>
>>>>>
>>>>> What I don't understand in your proposal, is where the attestation key
>>>>> comes from ? Who provides the initial trust that the key device at the
>>>>> client can be trusted ?
>>>>
>>>> Inside of the TEE.  AIFAIK, Apple already have an attestation key there.
>>> And how does the CA establish initial trust in the Apple attestation key
>>> ? I've never seen such a key and I doubt that Apple will provide any
>>> assurance to a third party regarding such a key.
>>>
>>> You need a better scheme if you want key attestation.
>>
>> FWIW, that's probably all that you can get.  I'm sure that such
>> a key will contain the usual BS like "NOT FIT FOR ANY PURPOSE ETC"
>> which US legislation requires :-)
>>
>> Anders
>>
>>>>
>>>> Anders
>>>>
>>>>>
>>>>> Andreas
>>>>>
>>>>> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>>>>>
>>>>> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>>>>>> Follow-up on the TPM is dead posting...
>>>>>>
>>>>>> It doesn't matter if hell freezes over, Smart Cards will never be
>>>>>> able to do this:
>>>>>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>>>>>
>>>>>>
>>>>>> If you don't have an Android device (or 5-10 minutes to spend...),
>>>>>> here is a short description:
>>>>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>>>>>
>>>>>>
>>>>>>
>>>>>> The idea is that the scheme should be a part of a standard phone.
>>>>>> Keys would be protected by a TEE and hopefully by a Security Enclave
>>>>>> as well.
>>>>>>
>>>>>> Anders
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Want fast and easy access to all the code in your enterprise? Index
>>>>>> and
>>>>>> search up to 200,000 lines of code with a free copy of Black
>>>>>> Duck®
>>>>>> Code Sight™ - the same software that powers the world's largest
>>>>>> code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Opensc-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>>>> Code Sight™ - the same software that powers the world's largest
>>>>> code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>
>>>
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Andreas Schwier (ML)
On 07/14/2014 12:57 PM, Anders Rundgren wrote:

> On 2014-07-14 12:46, Andreas Schwier wrote:
>> OTA is the right keyword in your post: OTA works end-to-end between the
>> OTA server and the SIM. It ensures trusted communication between the
>> device and the CA. The CA knows the keys are from a genuine device
>> provided and managed by the MNO.
>>
>> So device management here has nothing to do with the browser process for
>> enrolment.
>
> With OTA I only meant "the Mobile Internet".
>
>>
>> You could even have a secure key store deployed anywhere remote and do
>> provisioning from a central key management system - the core principle
>> remains the same: Trusted communication between the device and the
>> managing entity.
>
> This is what the described system claims to support.  The only difference
> to your system is that the device doesn't care who the management entity
> is.
>
> I.e. there are no predefined relations such as imposed by SCP02.
Same thing here: Because the secure channel is not based on shared
secrets between the device and the server, but is established using chip
authentication as defined in TR-03110. As each device has a
cryptographically verifiable identity, the server knows who he's talking to.

>
>>
>> Putting that into a browser without the link to the key storing device
>> is nothing better than the current KEYGEN protocol in Firefox and alike.
>
> SKS/KeyGen2 does a lot of things KEYGEN does not.  The security is as good
> as the TEE can offer.  No more, no less.
>
> If you try the PoC you can see the device bindings which also plays a
> role here.
>
>>
>> That's why we split things: There is a provisioning layer using
>> RAMOverHTTP that establishes a trusted link between the device and the
>> server and this layer is activated from within the web application.
>> However, the provisioning layer also works independent of the browser in
>> rich clients or just as a shell script on a remote machine.
>>
>> And yes, RAMOverHTTP works on an APDU level, because that is the natural
>> communication mechanism that reaches all the way into the device.
>
> That is what Gemalto thinks as well:
> http://opoto.github.io/secure-element
>
> The browser vendors do (AFAICT) not intend to support this work.
Who is Gemalto ?

>
> Anders
>
>>
>> On 07/14/2014 12:27 PM, Anders Rundgren wrote:
>>> On 2014-07-14 12:07, Andreas Schwier wrote:
>>>> On 07/14/2014 11:33 AM, Anders Rundgren wrote:
>>>>> On 2014-07-14 11:28, Andreas Schwier wrote:
>>>>>> Hi Anders,
>>>>>>
>>>>>> why do you think that Smart Cards will never be able to do that ?
>>>>>
>>>>> Because the smart card industry have no connections with the browser
>>>>> vendors, never had.
>>>
>>> DISCLAIMER:
>>> The thing I described is my take on the subject, there is nothing
>>> that says that my take will prevail.  But I believe that something along
>>> these line will.
>>>
>>>
>>>
>>>> Maybe I don't understand what key provisioning has to do with the
>>>> browser.
>>>
>>> If we are talking consumers, they interact with services with the
>>> browser.
>>> Services may provide keys through the very same "universal interface".
>>> This is the use-case for the stuff I'm working on.
>>>
>>>
>>>> IMHO it has to do with a RA process that identifies the
>>>> applicant, establishes a link between the public key and identification
>>>> data and issues a certificate. PKCS#10 already does a good job, it's
>>>> just missing the assurance of a secure and identified key store - in
>>>> case as a CA you want to make sure the key exists only once and you
>>>> want
>>>> to know where. If as a CA you don't care, then proof-of-possession for
>>>> the private key is sufficient.
>>>
>>> This process is not standardized and none of the browser-based
>>> enrollment
>>> systems out there (MSIE, Firefox, Chrome) even deal with PIN-codes.
>>> For smart cards you usually have to initialize the key entry locally
>>> using some proprietary SW.
>>>
>>> The US government had their chance when they defined PIV but they never
>>> thought outside of the federal-government-box and that was [probably]
>>> the last shot the smart card industry got on creating an Internet-ready
>>> PKI-card.
>>>
>>>
>>>>>>
>>>>>> The SmartCard-HSM is functionality-wise doing exactly the same [1]
>>>>>> and
>>>>>
>>>>> Would you say that this is consumer solution?
>>>> Absolutely. Like the physical keys on my key ring, I want a device for
>>>> my cryptographic key that I can put in my pocket. If I need the key, I
>>>> plug that device into a PC or hold it to the NFC reader in my mobile
>>>> and
>>>> perform the crypto operation. I don't leave the keys in the lock.
>>>>
>>>> Like I have an USB-Stick for my data, I have an USB-Stick for my keys.
>>>
>>> I was referring to the initialization of it OTA.
>>>
>>>>>
>>>>>
>>>>>> FIDO has a similar scheme for key attestation.
>>>>>
>>>>> FIDO does not support PKI.
>>>> That's one of the FIDO shortcomings. It only sorts out the problem of
>>>> authentication, but I also want to securely store my keys to sign
>>>> documents or decrypt data. FIDO is not a universal key store - but a
>>>> universal key store is what makes sense IMHO.
>>>
>>> Yes, this is the core of my line of work.
>>>
>>>>>
>>>>>>
>>>>>> What I don't understand in your proposal, is where the attestation
>>>>>> key
>>>>>> comes from ? Who provides the initial trust that the key device at
>>>>>> the
>>>>>> client can be trusted ?
>>>>>
>>>>> Inside of the TEE.  AIFAIK, Apple already have an attestation key
>>>>> there.
>>>> And how does the CA establish initial trust in the Apple attestation
>>>> key
>>>> ? I've never seen such a key and I doubt that Apple will provide any
>>>> assurance to a third party regarding such a key.
>>>>
>>>> You need a better scheme if you want key attestation.
>>>
>>> FWIW, that's probably all that you can get.  I'm sure that such
>>> a key will contain the usual BS like "NOT FIT FOR ANY PURPOSE ETC"
>>> which US legislation requires :-)
>>>
>>> Anders
>>>
>>>>>
>>>>> Anders
>>>>>
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>>>>>>
>>>>>> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>>>>>>> Follow-up on the TPM is dead posting...
>>>>>>>
>>>>>>> It doesn't matter if hell freezes over, Smart Cards will never be
>>>>>>> able to do this:
>>>>>>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If you don't have an Android device (or 5-10 minutes to spend...),
>>>>>>> here is a short description:
>>>>>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The idea is that the scheme should be a part of a standard phone.
>>>>>>> Keys would be protected by a TEE and hopefully by a Security Enclave
>>>>>>> as well.
>>>>>>>
>>>>>>> Anders
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Want fast and easy access to all the code in your enterprise? Index
>>>>>>> and
>>>>>>> search up to 200,000 lines of code with a free copy of Black
>>>>>>> Duck®
>>>>>>> Code Sight™ - the same software that powers the world's largest
>>>>>>> code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Opensc-devel mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> Want fast and easy access to all the code in your enterprise?
>>>>>> Index and
>>>>>> search up to 200,000 lines of code with a free copy of Black
>>>>>> Duck®
>>>>>> Code Sight™ - the same software that powers the world's largest
>>>>>> code
>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>> http://p.sf.net/sfu/bds
>>>>>> _______________________________________________
>>>>>> Opensc-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>
>>>>>
>>>>
>>>
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Smart Cards vs. TEEs

Anders Rundgren-2
So I guess it all boils down to the support via the browser.
The smart card industry have no plan and that will cost them a lot.

Anders

On 2014-07-14 13:39, Andreas Schwier wrote:

> On 07/14/2014 12:57 PM, Anders Rundgren wrote:
>> On 2014-07-14 12:46, Andreas Schwier wrote:
>>> OTA is the right keyword in your post: OTA works end-to-end between the
>>> OTA server and the SIM. It ensures trusted communication between the
>>> device and the CA. The CA knows the keys are from a genuine device
>>> provided and managed by the MNO.
>>>
>>> So device management here has nothing to do with the browser process for
>>> enrolment.
>>
>> With OTA I only meant "the Mobile Internet".
>>
>>>
>>> You could even have a secure key store deployed anywhere remote and do
>>> provisioning from a central key management system - the core principle
>>> remains the same: Trusted communication between the device and the
>>> managing entity.
>>
>> This is what the described system claims to support.  The only difference
>> to your system is that the device doesn't care who the management entity
>> is.
>>
>> I.e. there are no predefined relations such as imposed by SCP02.
> Same thing here: Because the secure channel is not based on shared
> secrets between the device and the server, but is established using chip
> authentication as defined in TR-03110. As each device has a
> cryptographically verifiable identity, the server knows who he's talking to.
>>
>>>
>>> Putting that into a browser without the link to the key storing device
>>> is nothing better than the current KEYGEN protocol in Firefox and alike.
>>
>> SKS/KeyGen2 does a lot of things KEYGEN does not.  The security is as good
>> as the TEE can offer.  No more, no less.
>>
>> If you try the PoC you can see the device bindings which also plays a
>> role here.
>>
>>>
>>> That's why we split things: There is a provisioning layer using
>>> RAMOverHTTP that establishes a trusted link between the device and the
>>> server and this layer is activated from within the web application.
>>> However, the provisioning layer also works independent of the browser in
>>> rich clients or just as a shell script on a remote machine.
>>>
>>> And yes, RAMOverHTTP works on an APDU level, because that is the natural
>>> communication mechanism that reaches all the way into the device.
>>
>> That is what Gemalto thinks as well:
>> http://opoto.github.io/secure-element
>>
>> The browser vendors do (AFAICT) not intend to support this work.
> Who is Gemalto ?
>
>>
>> Anders
>>
>>>
>>> On 07/14/2014 12:27 PM, Anders Rundgren wrote:
>>>> On 2014-07-14 12:07, Andreas Schwier wrote:
>>>>> On 07/14/2014 11:33 AM, Anders Rundgren wrote:
>>>>>> On 2014-07-14 11:28, Andreas Schwier wrote:
>>>>>>> Hi Anders,
>>>>>>>
>>>>>>> why do you think that Smart Cards will never be able to do that ?
>>>>>>
>>>>>> Because the smart card industry have no connections with the browser
>>>>>> vendors, never had.
>>>>
>>>> DISCLAIMER:
>>>> The thing I described is my take on the subject, there is nothing
>>>> that says that my take will prevail.  But I believe that something along
>>>> these line will.
>>>>
>>>>
>>>>
>>>>> Maybe I don't understand what key provisioning has to do with the
>>>>> browser.
>>>>
>>>> If we are talking consumers, they interact with services with the
>>>> browser.
>>>> Services may provide keys through the very same "universal interface".
>>>> This is the use-case for the stuff I'm working on.
>>>>
>>>>
>>>>> IMHO it has to do with a RA process that identifies the
>>>>> applicant, establishes a link between the public key and identification
>>>>> data and issues a certificate. PKCS#10 already does a good job, it's
>>>>> just missing the assurance of a secure and identified key store - in
>>>>> case as a CA you want to make sure the key exists only once and you
>>>>> want
>>>>> to know where. If as a CA you don't care, then proof-of-possession for
>>>>> the private key is sufficient.
>>>>
>>>> This process is not standardized and none of the browser-based
>>>> enrollment
>>>> systems out there (MSIE, Firefox, Chrome) even deal with PIN-codes.
>>>> For smart cards you usually have to initialize the key entry locally
>>>> using some proprietary SW.
>>>>
>>>> The US government had their chance when they defined PIV but they never
>>>> thought outside of the federal-government-box and that was [probably]
>>>> the last shot the smart card industry got on creating an Internet-ready
>>>> PKI-card.
>>>>
>>>>
>>>>>>>
>>>>>>> The SmartCard-HSM is functionality-wise doing exactly the same [1]
>>>>>>> and
>>>>>>
>>>>>> Would you say that this is consumer solution?
>>>>> Absolutely. Like the physical keys on my key ring, I want a device for
>>>>> my cryptographic key that I can put in my pocket. If I need the key, I
>>>>> plug that device into a PC or hold it to the NFC reader in my mobile
>>>>> and
>>>>> perform the crypto operation. I don't leave the keys in the lock.
>>>>>
>>>>> Like I have an USB-Stick for my data, I have an USB-Stick for my keys.
>>>>
>>>> I was referring to the initialization of it OTA.
>>>>
>>>>>>
>>>>>>
>>>>>>> FIDO has a similar scheme for key attestation.
>>>>>>
>>>>>> FIDO does not support PKI.
>>>>> That's one of the FIDO shortcomings. It only sorts out the problem of
>>>>> authentication, but I also want to securely store my keys to sign
>>>>> documents or decrypt data. FIDO is not a universal key store - but a
>>>>> universal key store is what makes sense IMHO.
>>>>
>>>> Yes, this is the core of my line of work.
>>>>
>>>>>>
>>>>>>>
>>>>>>> What I don't understand in your proposal, is where the attestation
>>>>>>> key
>>>>>>> comes from ? Who provides the initial trust that the key device at
>>>>>>> the
>>>>>>> client can be trusted ?
>>>>>>
>>>>>> Inside of the TEE.  AIFAIK, Apple already have an attestation key
>>>>>> there.
>>>>> And how does the CA establish initial trust in the Apple attestation
>>>>> key
>>>>> ? I've never seen such a key and I doubt that Apple will provide any
>>>>> assurance to a third party regarding such a key.
>>>>>
>>>>> You need a better scheme if you want key attestation.
>>>>
>>>> FWIW, that's probably all that you can get.  I'm sure that such
>>>> a key will contain the usual BS like "NOT FIT FOR ANY PURPOSE ETC"
>>>> which US legislation requires :-)
>>>>
>>>> Anders
>>>>
>>>>>>
>>>>>> Anders
>>>>>>
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>> [1] http://www.coolpacs.org/docs/coolPACS_V1.2_2013-04-08.pdf
>>>>>>>
>>>>>>> On 07/14/2014 11:10 AM, Anders Rundgren wrote:
>>>>>>>> Follow-up on the TPM is dead posting...
>>>>>>>>
>>>>>>>> It doesn't matter if hell freezes over, Smart Cards will never be
>>>>>>>> able to do this:
>>>>>>>> https://play.google.com/store/apps/details?id=org.webpki.mobile.android
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If you don't have an Android device (or 5-10 minutes to spend...),
>>>>>>>> here is a short description:
>>>>>>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The idea is that the scheme should be a part of a standard phone.
>>>>>>>> Keys would be protected by a TEE and hopefully by a Security Enclave
>>>>>>>> as well.
>>>>>>>>
>>>>>>>> Anders
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Want fast and easy access to all the code in your enterprise? Index
>>>>>>>> and
>>>>>>>> search up to 200,000 lines of code with a free copy of Black
>>>>>>>> Duck®
>>>>>>>> Code Sight™ - the same software that powers the world's largest
>>>>>>>> code
>>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>>> http://p.sf.net/sfu/bds
>>>>>>>> _______________________________________________
>>>>>>>> Opensc-devel mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Want fast and easy access to all the code in your enterprise?
>>>>>>> Index and
>>>>>>> search up to 200,000 lines of code with a free copy of Black
>>>>>>> Duck®
>>>>>>> Code Sight™ - the same software that powers the world's largest
>>>>>>> code
>>>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>>>> http://p.sf.net/sfu/bds
>>>>>>> _______________________________________________
>>>>>>> Opensc-devel mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel