Technical Description - Android Embedded SE

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

Technical Description - Android Embedded SE

Anders Rundgren
http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html

Very interesting IMHO.

According to the author SD-slots are becoming exceptions also for Android so this is
probably what most people will be dealing with.

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: Technical Description - Android Embedded SE

Andreas Jellinghaus-4


Am 20.09.2012 21:06 schrieb "Anders Rundgren" <[hidden email]>:
>
> http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html
>
> Very interesting IMHO.

Agree, thanks for sharing.
>
> According to the author SD-slots are becoming exceptions also for Android so this is
> probably what most people will be dealing with.

I think he is also over optimistic with multi applications on a Java card SE, but we will see.

The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome...

Andreas
>
> Anders
>
> _______________________________________________
> 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: Technical Description - Android Embedded SE

Anders Rundgren
On 2012-09-22 08:58, Andreas Jellinghaus wrote:

>
> Am 20.09.2012 21:06 schrieb "Anders Rundgren" <[hidden email] <mailto:[hidden email]>>:
>>
>> http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html
>>
>> Very interesting IMHO.
>
> Agree, thanks for sharing.
>>
>> According to the author SD-slots are becoming exceptions also for Android so this is
>> probably what most people will be dealing with.
>
> I think he is also over optimistic with multi applications on a Java card SE, but we will see.
Indeed.  I even wonder if the SE needs to host "applications" at all.  IMO, it would be enough
if the SE hosts keys and associated attributes while the applications either rather run at OS-level
as trusted processes like PIN input etc. or as standard applications.  As far as I understand
the Wallet is just an Android "App" that is trusted by the SE.

In my mind keys could optionally contain application-oriented ACL telling which
applications they trust so that even if you install a "bad" App, it would for
example not be able to use your bank or eID-key in the background.

Here is a write-up of a possible ACL-scheme that is intended for the Web and "App":
http://webpki.org/papers/PKI/pki-webcrypto.pdf

Anders

>
> The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome...
>
> Andreas
>>
>> Anders
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email] <mailto:[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: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
2012/9/22 Anders Rundgren <[hidden email]>
On 2012-09-22 08:58, Andreas Jellinghaus wrote:
>
> Am 20.09.2012 21:06 schrieb "Anders Rundgren" <[hidden email] <mailto:[hidden email]>>:
>>
>> http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html
>>
>> Very interesting IMHO.
>
> Agree, thanks for sharing.
>>
>> According to the author SD-slots are becoming exceptions also for Android so this is
>> probably what most people will be dealing with.
>
> I think he is also over optimistic with multi applications on a Java card SE, but we will see.
Indeed.  I even wonder if the SE needs to host "applications" at all.  IMO, it would be enough
if the SE hosts keys and associated attributes while the applications either rather run at OS-level
as trusted processes like PIN input etc. or as standard applications.  As far as I understand
the Wallet is just an Android "App" that is trusted by the SE.

well, even if the battery of the mobile phone is empty, the secure element can still be powered by any
reader and thus still work. Implementations can or cannot make use of this - if the implementation prefers
the user to take the phone out of his bag, unlock it, open some app and make the "I approve" gesture, 
then disabling it is a good idea to prevent unauthorized usage.

In my mind keys could optionally contain application-oriented ACL telling which
applications they trust so that even if you install a "bad" App, it would for
example not be able to use your bank or eID-key in the background.

I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart
card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is
loaded into such a container, limiting it and reserving the unallocated space for further applications/containers?

Is there a standard on doing this, or is it all JCOP magic under NDA?

I only remember seeing code that would change master keys and put one app into a card, thus never bothered how it works in detail or how to manage resource, secure apps against each other etc. Also I wonder: does the vendor claim to have the security thight enough to prevent a hostile app from accessing data of another app? Or is it the usual "all is secure", but we don't tell how it works,
how to use it, and make no real guaranties anyway?
 
Here is a write-up of a possible ACL-scheme that is intended for the Web and "App":
http://webpki.org/papers/PKI/pki-webcrypto.pdf

hmm, that link is configured as download :( a normal link would be easier so chrome users can browse it
without a download to the filesystem (and another file kept around in Dowload/ folder forever).

I haven't looked into this into very detailed. 

My new impression is I would only need to use a smart card key&cert with one site only - my SSO provider. Thus a plugin for that communication only would work well with me.

I use two browsers, thus could have a differnt plugin each time linked to a different identity. Not sure if I wanted to share a card for that purpose, that agains simplifies my requirements I would have for a smart card a lot.

Like many people I noticed that people have their mobile phone with them all the time, and notice if they lost it right away.
Thus using a mobile phone for authenticating any other device seems to be the right thing to do and works well for many people
in practice. Thus using the SE in such a phone can become interesting. Not sure what to do about phone theft though - I really fear putting all the access credentials into one basket (my phone), plus a lot of personal information, so any thief would be able to
impersonate me and access my mail, documents, banks, and much more.

In summary: my old expectations how to secure communication and use smart cards in them have gone many months ago, now I see the "world" very differently. My adventures into smart card business also make me wonder if trusting such an industry is a good thing.

Andreas
 


Anders

>
> The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome...
>
> Andreas
>>
>> Anders
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email] <mailto:[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: Technical Description - Android Embedded SE

NdK-3
Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:

>     In my mind keys could optionally contain application-oriented ACL
>     telling which
>     applications they trust so that even if you install a "bad" App, it
>     would for
>     example not be able to use your bank or eID-key in the background.
In my mind, the SE should take over display and touch controller by
hardware means, so absolutely no app can snoop user input or fake it.
Too bad seems nobody really *needs* that level of security...

> I must admit I don't know how many apps are managed and seperated. given
> the restricted resources a smart card has,
Think about how an MMU works: it keeps a table of "pages" assigned to an
app, and maps 'em in app's address space. An app have no way to access a
page outside its allowed address space. Nothing secret, here, and
doesn't require great resources.

> I only remember seeing code that would change master keys and put one
> app into a card, thus never bothered how it works in detail or how to
> manage resource, secure apps against each other etc. Also I wonder: does
> the vendor claim to have the security thight enough to prevent a hostile
> app from accessing data of another app? Or is it the usual "all is
> secure", but we don't tell how it works,
> how to use it, and make no real guaranties anyway?
Another question: if the applet manager is secure, then why change
master keys before giving a card to customers?

> My new impression is I would only need to use a smart card key&cert with
> one site only - my SSO provider. Thus a plugin for that communication
> only would work well with me.
As long as you can import/export your cert (better if keeping it
protected by a password) then you can have quite good security using
openid and an identity provider like startssl that authenticates you
using that cert.

> Not sure what to do about phone theft though - I really fear putting all
> the access credentials into one basket (my phone), plus a lot of
> personal information, so any thief would be able to
> impersonate me and access my mail, documents, banks, and much more.
For this I simply use keepass w/ its db synced over dropbox (and backed
up offline in multiple places). Obviously a thief wouldn't have my
master password, so the access to the db would be useless.

> In summary: my old expectations how to secure communication and use
> smart cards in them have gone many months ago, now I see the "world"
> very differently. My adventures into smart card business also make me
> wonder if trusting such an industry is a good thing.
Always too many things under NDA or plainly unavailable, too often
starting from comm specs...

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

Re: Technical Description - Android Embedded SE

Anders Rundgren
On 2012-09-22 17:27, NdK wrote:
> Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
>
>>     In my mind keys could optionally contain application-oriented ACL
>>     telling which
>>     applications they trust so that even if you install a "bad" App, it
>>     would for
>>     example not be able to use your bank or eID-key in the background.

> In my mind, the SE should take over display and touch controller by
> hardware means, so absolutely no app can snoop user input or fake it.
> Too bad seems nobody really *needs* that level of security...

The problem with that is that is impossible for a user to distinguish
between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
this particular issue is that there is an OS-based PIN dialog and that
keys can specify that they only accepts PINs through the system PIN dialog
(trusted path).

If the user is presented a spoofed PIN dialog, the attacker may indeed get
the PIN.  However, the attacker must also take the device as well in order
to use it which makes the attack much less useful.

If the OS is hacked this doesn't help but it seems that this is not
the biggest problem with mobile devices; it is rather determine what
an app should be able to do or not.

To get the proportions right, consumer security solutions should IMO be
compared with the "Gold Standard" for Internet-payments where authorization
is performed by a "UserID" (Card Number) and "Password" (CCV) printed in
clear on plastic cards, which is all the Financial Industry have manged to
roll out during the 15Y+ we have had with the Internet!

Anders


>
>> I must admit I don't know how many apps are managed and seperated. given
>> the restricted resources a smart card has,
> Think about how an MMU works: it keeps a table of "pages" assigned to an
> app, and maps 'em in app's address space. An app have no way to access a
> page outside its allowed address space. Nothing secret, here, and
> doesn't require great resources.
>
>> I only remember seeing code that would change master keys and put one
>> app into a card, thus never bothered how it works in detail or how to
>> manage resource, secure apps against each other etc. Also I wonder: does
>> the vendor claim to have the security thight enough to prevent a hostile
>> app from accessing data of another app? Or is it the usual "all is
>> secure", but we don't tell how it works,
>> how to use it, and make no real guaranties anyway?
> Another question: if the applet manager is secure, then why change
> master keys before giving a card to customers?
>
>> My new impression is I would only need to use a smart card key&cert with
>> one site only - my SSO provider. Thus a plugin for that communication
>> only would work well with me.
> As long as you can import/export your cert (better if keeping it
> protected by a password) then you can have quite good security using
> openid and an identity provider like startssl that authenticates you
> using that cert.
>
>> Not sure what to do about phone theft though - I really fear putting all
>> the access credentials into one basket (my phone), plus a lot of
>> personal information, so any thief would be able to
>> impersonate me and access my mail, documents, banks, and much more.
> For this I simply use keepass w/ its db synced over dropbox (and backed
> up offline in multiple places). Obviously a thief wouldn't have my
> master password, so the access to the db would be useless.
>
>> In summary: my old expectations how to secure communication and use
>> smart cards in them have gone many months ago, now I see the "world"
>> very differently. My adventures into smart card business also make me
>> wonder if trusting such an industry is a good thing.
> Always too many things under NDA or plainly unavailable, too often
> starting from comm specs...
>
> BYtE,
>  Diego.
> _______________________________________________
> 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: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
In reply to this post by NdK-3
2012/9/22 NdK <[hidden email]>
Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:

>     In my mind keys could optionally contain application-oriented ACL
>     telling which
>     applications they trust so that even if you install a "bad" App, it
>     would for
>     example not be able to use your bank or eID-key in the background.
In my mind, the SE should take over display and touch controller by
hardware means, so absolutely no app can snoop user input or fake it.
Too bad seems nobody really *needs* that level of security...

like "credsticks" from scifi novels decades ago? that owuld be a single use appliance, and I think easy to hack, similar how it is trivial to have a chip recording keystrokes placed inside a laptop etc. and I guess a multi app would be extreme complex and unlikely to be secure either.

> I must admit I don't know how many apps are managed and seperated. given
> the restricted resources a smart card has,
Think about how an MMU works: it keeps a table of "pages" assigned to an
app, and maps 'em in app's address space. An app have no way to access a
page outside its allowed address space. Nothing secret, here, and
doesn't require great resources.

hmm, a datasheat I found on smartmx for example does not mention a MMU.
I guess it is onl a software implementation in the java interpreter, and that could be well faulty.
also how are things managed - how easy is it to setup things wrong? 

> I only remember seeing code that would change master keys and put one
> app into a card, thus never bothered how it works in detail or how to
> manage resource, secure apps against each other etc. Also I wonder: does
> the vendor claim to have the security thight enough to prevent a hostile
> app from accessing data of another app? Or is it the usual "all is
> secure", but we don't tell how it works,
> how to use it, and make no real guaranties anyway?
Another question: if the applet manager is secure, then why change
master keys before giving a card to customers?

cards go throug a pipeline of ~4 entities and everyone has his own secret key that he doesn't want to give out.
first there is the chip key by the cpu vendor. then the mask of the OS vendor has a different master key, so from
serial and the mask a new key is set. then the OS manufacturer changes the key again as soon as he gets the hand
on the chips, as the cpu manufacturer can see the master key in the mask. then he wants to send the chips to some
perso unit, so he has a master key agreed on between the os vendor and the perso provider, and changes the card
key to be derviced from this. the perso provider could change the key again when receiving the cards, but he needs
to trust the card or provider anyway, and might be too lazy. but once he manufacturers a card, he has a master
key agreed on with the customer, e.g. a bank. and now the card key is changed again. in this step the old key
is derived from the card serial, as in all previous steps, but the new key is derived from the number of e.g. the visa card,
not the chip. again the bank could then change the cards key later, e.g. using an update procedure in an ATM.
which noone does, because it never works well, but in theory ...

this procedure is not entirely accurate, as e.g. os vendors move towards hosting equipment directly at the CPU manufacturer,
so the cards are changed on site, and can be directly send to perso units, which will safe them manual extra work and one security transport - those are quite expensive.

so for SE in mobile phones we would have the same more or less - e.g. NXP does the chip and the OS (if the two units trust each other they can skip one change to the key here), then the sell the chip to samsung and change the key to the nxp-samsung-$chip MK derived one first, samsung might want to change the key again, and sell the device. but if banks need to trust the device enough to upload a smart card into it, then the end user can't have the key for his device - otherwise he could decrypt the communication and create several copies of the credit card uploaded, great for fraud, but security of those depends on single unique cards.
 
> My new impression is I would only need to use a smart card key&cert with
> one site only - my SSO provider. Thus a plugin for that communication
> only would work well with me.
As long as you can import/export your cert (better if keeping it
protected by a password) then you can have quite good security using
openid and an identity provider like startssl that authenticates you
using that cert.

certs don't need protection, only keys do. and being able to export a key is always a bad idea.
it is much better to be able to get a new cert&key whenever you want on demand. e.g. enter your credentials
(password, pin, tan, fingerprint, retina scan, secret handshake, whatever you think is secure) and then get/generate
a new keypair and CSR and get the signed cert.

as for openid, I thought there was some discussion about it - v1 too complex, not much agreement on v2 or so?
 
> Not sure what to do about phone theft though - I really fear putting all
> the access credentials into one basket (my phone), plus a lot of
> personal information, so any thief would be able to
> impersonate me and access my mail, documents, banks, and much more.
For this I simply use keepass w/ its db synced over dropbox (and backed
up offline in multiple places). Obviously a thief wouldn't have my
master password, so the access to the db would be useless.

well, unless it can be sniffed or brute forced...
but this is a sound trust decission - we need to be aware of the attack vectors though. 

> In summary: my old expectations how to secure communication and use
> smart cards in them have gone many months ago, now I see the "world"
> very differently. My adventures into smart card business also make me
> wonder if trusting such an industry is a good thing.
Always too many things under NDA or plainly unavailable, too often
starting from comm specs...

common specs? I rather wonder: everyone invented something on his own, and when a standard came around, any change would break compatibility and more important require new certification rounds, thus would be expensive, thus everyyone preferred to not implement the standard. after all who wants to give users the choice to switch vendors? very bad idea, vendor lockin is king,

it seems to change now with many the consolidation phase - unless you need to be compatible to something old, there are few products left. outside of card standards enforced by the customers - telco for sim cards and visa/master card for credit cards - cards were incompatible forever, but now mostly JCOP survives and everyone else stopped improving their cards? I haven't seen many new card operating systems released in the last years at least. and at least for small developers I'm not aware that you can buy other java cards than JCOP. And JCOP again is a prime example of a NDA thing, not a standard, right? or did it improve?

Andreas


BYtE,
 Diego.
_______________________________________________
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: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
In reply to this post by Anders Rundgren
2012/9/22 Anders Rundgren <[hidden email]>
On 2012-09-22 17:27, NdK wrote:
> Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
>
>>     In my mind keys could optionally contain application-oriented ACL
>>     telling which
>>     applications they trust so that even if you install a "bad" App, it
>>     would for
>>     example not be able to use your bank or eID-key in the background.

> In my mind, the SE should take over display and touch controller by
> hardware means, so absolutely no app can snoop user input or fake it.
> Too bad seems nobody really *needs* that level of security...

The problem with that is that is impossible for a user to distinguish
between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
this particular issue is that there is an OS-based PIN dialog and that
keys can specify that they only accepts PINs through the system PIN dialog
(trusted path).

If the user is presented a spoofed PIN dialog, the attacker may indeed get
the PIN.  However, the attacker must also take the device as well in order
to use it which makes the attack much less useful.

If the OS is hacked this doesn't help but it seems that this is not
the biggest problem with mobile devices; it is rather determine what
an app should be able to do or not.

To get the proportions right, consumer security solutions should IMO be
compared with the "Gold Standard" for Internet-payments where authorization
is performed by a "UserID" (Card Number) and "Password" (CCV) printed in
clear on plastic cards, which is all the Financial Industry have manged to
roll out during the 15Y+ we have had with the Internet!

actually I think the system was doing fine - if you can review transactions later
and refute any bogus transaction and the money can be traced to the recipient,
and the system provider has a huge interest to keep the money traceable and
recall'able, that is a good system design, and protects everyone much better than
technical adventures.

The downside from my perspective is rather that visa and master card are shifting the liability to the end user.
if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having
a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require
the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan
as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty
bank account.

Lets be honest: you might have your mobile phone and wallet in your hand-bag or backpack or whatever, and if
both are stolen the attacker has access to about everything and almost all ways to identify you and authorize
transactions are in his hand. even the numbers you might need to know to prevent fraud are no longer with you -
e.g. in germany I might remember the central hotline for reporting stolen cards (116 116) and I remember my bank
account number. but if they require my visa card number, I wouldn't know that. also I wouldn't have mobile phone
with me - it got stolen - and if I don't notice the issue I'm out of luck, as everyone (banks, telco, ...) shift the liability
for every transaction until the theft gets reported to the customer.

the mobile phones have authentication of the customer (gesture, pin, password or screen unlock), but those are not very good protections. so my expectation is they won't stop attackers.

Andreas
 

Anders


>
>> I must admit I don't know how many apps are managed and seperated. given
>> the restricted resources a smart card has,
> Think about how an MMU works: it keeps a table of "pages" assigned to an
> app, and maps 'em in app's address space. An app have no way to access a
> page outside its allowed address space. Nothing secret, here, and
> doesn't require great resources.
>
>> I only remember seeing code that would change master keys and put one
>> app into a card, thus never bothered how it works in detail or how to
>> manage resource, secure apps against each other etc. Also I wonder: does
>> the vendor claim to have the security thight enough to prevent a hostile
>> app from accessing data of another app? Or is it the usual "all is
>> secure", but we don't tell how it works,
>> how to use it, and make no real guaranties anyway?
> Another question: if the applet manager is secure, then why change
> master keys before giving a card to customers?
>
>> My new impression is I would only need to use a smart card key&cert with
>> one site only - my SSO provider. Thus a plugin for that communication
>> only would work well with me.
> As long as you can import/export your cert (better if keeping it
> protected by a password) then you can have quite good security using
> openid and an identity provider like startssl that authenticates you
> using that cert.
>
>> Not sure what to do about phone theft though - I really fear putting all
>> the access credentials into one basket (my phone), plus a lot of
>> personal information, so any thief would be able to
>> impersonate me and access my mail, documents, banks, and much more.
> For this I simply use keepass w/ its db synced over dropbox (and backed
> up offline in multiple places). Obviously a thief wouldn't have my
> master password, so the access to the db would be useless.
>
>> In summary: my old expectations how to secure communication and use
>> smart cards in them have gone many months ago, now I see the "world"
>> very differently. My adventures into smart card business also make me
>> wonder if trusting such an industry is a good thing.
> Always too many things under NDA or plainly unavailable, too often
> starting from comm specs...
>
> BYtE,
>  Diego.
> _______________________________________________
> 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


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

Re: Technical Description - Android Embedded SE

Anders Rundgren
On 2012-09-23 12:04, Andreas Jellinghaus wrote:

> 2012/9/22 Anders Rundgren <[hidden email] <mailto:[hidden email]>>
>
>     On 2012-09-22 17:27, NdK wrote:
>     > Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
>     >
>     >>     In my mind keys could optionally contain application-oriented ACL
>     >>     telling which
>     >>     applications they trust so that even if you install a "bad" App, it
>     >>     would for
>     >>     example not be able to use your bank or eID-key in the background.
>
>     > In my mind, the SE should take over display and touch controller by
>     > hardware means, so absolutely no app can snoop user input or fake it.
>     > Too bad seems nobody really *needs* that level of security...
>
>     The problem with that is that is impossible for a user to distinguish
>     between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
>     this particular issue is that there is an OS-based PIN dialog and that
>     keys can specify that they only accepts PINs through the system PIN dialog
>     (trusted path).
>
>     If the user is presented a spoofed PIN dialog, the attacker may indeed get
>     the PIN.  However, the attacker must also take the device as well in order
>     to use it which makes the attack much less useful.
>
>     If the OS is hacked this doesn't help but it seems that this is not
>     the biggest problem with mobile devices; it is rather determine what
>     an app should be able to do or not.
>
>     To get the proportions right, consumer security solutions should IMO be
>     compared with the "Gold Standard" for Internet-payments where authorization
>     is performed by a "UserID" (Card Number) and "Password" (CCV) printed in
>     clear on plastic cards, which is all the Financial Industry have manged to
>     roll out during the 15Y+ we have had with the Internet!
>
>
> actually I think the system was doing fine - if you can review transactions later
> and refute any bogus transaction and the money can be traced to the recipient,
> and the system provider has a huge interest to keep the money traceable and
> recall'able, that is a good system design, and protects everyone much better than
> technical adventures.

I guess you refer to the Google Wallet or SKS as "technical adventures"?  I don't
see any conflicts between judicious logging and systems that [rightly or wrongly]
are claimed to be more secure than passwords printed in clear on plastic cards.

>
> The downside from my perspective is rather that visa and master card are shifting the liability to the end user.
> if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having
> a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require
> the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan
> as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty
> bank account.

3D Secure IMO combines the worst possible user-interface with questionable security.
However, the concept is actually brilliant but it will rather be Google and Apple
that will make it useful, not MasterCard and VISA.

>
> Lets be honest: you might have your mobile phone and wallet in your hand-bag or backpack or whatever, and if
> both are stolen the attacker has access to about everything and almost all ways to identify you and authorize
> transactions are in his hand. even the numbers you might need to know to prevent fraud are no longer with you -
> e.g. in germany I might remember the central hotline for reporting stolen cards (116 116) and I remember my bank
> account number. but if they require my visa card number, I wouldn't know that. also I wouldn't have mobile phone
> with me - it got stolen - and if I don't notice the issue I'm out of luck, as everyone (banks, telco, ...) shift the liability
> for every transaction until the theft gets reported to the customer.
>
> the mobile phones have authentication of the customer (gesture, pin, password or screen unlock), but those are not
> very good protections. so my expectation is they won't stop attackers.

I expect another kind of protection to be more useful and that is that the owner will be able
to set it "on hold" or possibly even in "wipe out" mode through a cloud service that the phone will
interrogate every now and then.  If the cloud service isn't available you must issue a "difficult"
password before gaining access to the device.  From what I can deduct from the rather scarce
Wallet documents, this is more or less already in place.  If the device is subject to a shrewd
attack I guess only the traditional credential revocation will help.  The cloud service may
aid you with that as well.

I definitely believe that losing a mobile phone wallet will be less devastating than
losing a traditional one.  Naturally it has to be proved.  I believe there are a
billion or so "guinea pigs" out there who are wiling to try :-)

Anders



>
> Andreas
>  
>
>
>     Anders
>
>
>     >
>     >> I must admit I don't know how many apps are managed and seperated. given
>     >> the restricted resources a smart card has,
>     > Think about how an MMU works: it keeps a table of "pages" assigned to an
>     > app, and maps 'em in app's address space. An app have no way to access a
>     > page outside its allowed address space. Nothing secret, here, and
>     > doesn't require great resources.
>     >
>     >> I only remember seeing code that would change master keys and put one
>     >> app into a card, thus never bothered how it works in detail or how to
>     >> manage resource, secure apps against each other etc. Also I wonder: does
>     >> the vendor claim to have the security thight enough to prevent a hostile
>     >> app from accessing data of another app? Or is it the usual "all is
>     >> secure", but we don't tell how it works,
>     >> how to use it, and make no real guaranties anyway?
>     > Another question: if the applet manager is secure, then why change
>     > master keys before giving a card to customers?
>     >
>     >> My new impression is I would only need to use a smart card key&cert with
>     >> one site only - my SSO provider. Thus a plugin for that communication
>     >> only would work well with me.
>     > As long as you can import/export your cert (better if keeping it
>     > protected by a password) then you can have quite good security using
>     > openid and an identity provider like startssl that authenticates you
>     > using that cert.
>     >
>     >> Not sure what to do about phone theft though - I really fear putting all
>     >> the access credentials into one basket (my phone), plus a lot of
>     >> personal information, so any thief would be able to
>     >> impersonate me and access my mail, documents, banks, and much more.
>     > For this I simply use keepass w/ its db synced over dropbox (and backed
>     > up offline in multiple places). Obviously a thief wouldn't have my
>     > master password, so the access to the db would be useless.
>     >
>     >> In summary: my old expectations how to secure communication and use
>     >> smart cards in them have gone many months ago, now I see the "world"
>     >> very differently. My adventures into smart card business also make me
>     >> wonder if trusting such an industry is a good thing.
>     > Always too many things under NDA or plainly unavailable, too often
>     > starting from comm specs...
>     >
>     > BYtE,
>     >  Diego.
>     > _______________________________________________
>     > opensc-devel mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://www.opensc-project.org/mailman/listinfo/opensc-devel
>     >
>
>     _______________________________________________
>     opensc-devel mailing list
>     [hidden email] <mailto:[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: Technical Description - Android Embedded SE

NdK-3
In reply to this post by Anders Rundgren
Il 22/09/2012 19:37, Anders Rundgren ha scritto:

>> In my mind, the SE should take over display and touch controller by
>> hardware means, so absolutely no app can snoop user input or fake it.
>> Too bad seems nobody really *needs* that level of security...
> The problem with that is that is impossible for a user to distinguish
> between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
> this particular issue is that there is an OS-based PIN dialog and that
> keys can specify that they only accepts PINs through the system PIN dialog
> (trusted path).
That's quite easy to avoid: once the SE takes over the display, it can
prompt the user with an user-supplied message . Visa is doing something
similar with "securecode auth": when you're doing a payment, you get
redirected to their site, where you see a personalized prompt and have
to enter another password. If you don't see your own prompt, you don't
enter the password..

> If the user is presented a spoofed PIN dialog, the attacker may indeed get
> the PIN.  However, the attacker must also take the device as well in order
> to use it which makes the attack much less useful.
The only drawback would be that if the attacker, after stealing the
phone and hacking it to include the right message in the spoofer,
returns it to the legit user, waits for the spoof to intercept the PIN
and then steals it again... Quite unlikely :) and easily detectable: if
your phone "disappeared", change the prompt before connecting again to
the payment service: if you still see the old prompt, better to reflash
the phone and change *all* your passwords.

> If the OS is hacked this doesn't help but it seems that this is not
> the biggest problem with mobile devices; it is rather determine what
> an app should be able to do or not.
If SE takes over HW access (this could include accelerometers, since
they could be used to infer where the user is tapping -- paranoid
enoug?), then it can be secure even if the OS got hacked.

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

Re: Technical Description - Android Embedded SE

NdK-3
In reply to this post by Andreas Jellinghaus-4
Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto:

>> In my mind, the SE should take over display and touch controller by
>> hardware means, so absolutely no app can snoop user input or fake it.
>> Too bad seems nobody really *needs* that level of security...
> like "credsticks" from scifi novels decades ago? that owuld be a single use
> appliance, and I think easy to hack, similar how it is trivial to have a
> chip recording keystrokes placed inside a laptop etc. and I guess a multi
> app would be extreme complex and unlikely to be secure either.
Nope. Speaking of SE in smartphones here :)
You don't have much space inside a phone... Hopefully not enough to add
a logger chip. And a phone is really much more "tamper evident" than a
laptop...

> hmm, a datasheat I found on smartmx for example does not mention a MMU.
> I guess it is onl a software implementation in the java interpreter, and
> that could be well faulty.
Software-emulated MMU, then. Since it's so simple, it could well be
worth the reduction in gates at the expense of a little longer run time
-- but you are already running java, not optimized asm...
> also how are things managed - how easy is it to setup things wrong?
That should be impossible, if the card only allows fixed-size apps and
went under throrought testing.

>> Another question: if the applet manager is secure, then why change
>> master keys before giving a card to customers?
> cards go throug a pipeline of ~4 entities and everyone has his own secret
[...]
Uhm... Found. If the key was publicly known, a reseller could easily
remove an applet and replace it with another using the same app id and
the final user wouldn't be able to know.
If only the card manager would allow a per-app removal key...

>>> My new impression is I would only need to use a smart card key&cert with
>>> one site only - my SSO provider. Thus a plugin for that communication
>>> only would work well with me.
>> As long as you can import/export your cert (better if keeping it
>> protected by a password) then you can have quite good security using
>> openid and an identity provider like startssl that authenticates you
>> using that cert.
> certs don't need protection, only keys do. and being able to export a key
> is always a bad idea.
Unless you either can set up a multi-party RSA system or have another
way to recover a damaged key.
If exporting keys is always such a bad idea, then why root-CAs export
theirs? Simply to have a backup and obtain business continuity in case
of HSM failure.

> it is much better to be able to get a new cert&key whenever you want on
> demand. e.g. enter your credentials
> (password, pin, tan, fingerprint, retina scan, secret handshake, whatever
> you think is secure) and then get/generate
> a new keypair and CSR and get the signed cert.
Unless you run a CA. :)

> as for openid, I thought there was some discussion about it - v1 too
> complex, not much agreement on v2 or so?
Complex? Seems quite easy...

>> Always too many things under NDA or plainly unavailable, too often
>> starting from comm specs...
comm=communication , sorry.

> common specs? I rather wonder: everyone invented something on his own, and
> when a standard came around, any change would break compatibility and more
> important require new certification rounds, thus would be expensive, thus
> everyyone preferred to not implement the standard. after all who wants to
> give users the choice to switch vendors? very bad idea, vendor lockin is
> king,
I'm still waiting for ACS to tell me something about how can I use my
cryptomate64 token. I could have its "reader" recognized, but ACOS5
protocol is still unsupported (I found a project, but it seems still in
its early stages...).

> other java cards than JCOP. And JCOP again is a prime example of a NDA
> thing, not a standard, right? or did it improve?
I have some JCOP cards, but just lately I found how to authenticate with
the card manager using Alexander Petric's hints for gpshell.
If I have't to sign NDAs to develop my own applets and load'em on card,
then for me it's "open enough".
But I still don't know if I have enough info (for example: how do I
handle RSA crypto? I hope there's a library with public API for that...).

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

Re: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
In reply to this post by Anders Rundgren
2012/9/23 Anders Rundgren <[hidden email]>
On 2012-09-23 12:04, Andreas Jellinghaus wrote:
> 2012/9/22 Anders Rundgren <[hidden email] <mailto:[hidden email]>>
>
>     On 2012-09-22 17:27, NdK wrote:
>     > Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
>     >
>     >>     In my mind keys could optionally contain application-oriented ACL
>     >>     telling which
>     >>     applications they trust so that even if you install a "bad" App, it
>     >>     would for
>     >>     example not be able to use your bank or eID-key in the background.
>
>     > In my mind, the SE should take over display and touch controller by
>     > hardware means, so absolutely no app can snoop user input or fake it.
>     > Too bad seems nobody really *needs* that level of security...
>
>     The problem with that is that is impossible for a user to distinguish
>     between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
>     this particular issue is that there is an OS-based PIN dialog and that
>     keys can specify that they only accepts PINs through the system PIN dialog
>     (trusted path).
>
>     If the user is presented a spoofed PIN dialog, the attacker may indeed get
>     the PIN.  However, the attacker must also take the device as well in order
>     to use it which makes the attack much less useful.
>
>     If the OS is hacked this doesn't help but it seems that this is not
>     the biggest problem with mobile devices; it is rather determine what
>     an app should be able to do or not.
>
>     To get the proportions right, consumer security solutions should IMO be
>     compared with the "Gold Standard" for Internet-payments where authorization
>     is performed by a "UserID" (Card Number) and "Password" (CCV) printed in
>     clear on plastic cards, which is all the Financial Industry have manged to
>     roll out during the 15Y+ we have had with the Internet!
>
>
> actually I think the system was doing fine - if you can review transactions later
> and refute any bogus transaction and the money can be traced to the recipient,
> and the system provider has a huge interest to keep the money traceable and
> recall'able, that is a good system design, and protects everyone much better than
> technical adventures.

I guess you refer to the Google Wallet or SKS as "technical adventures"?  I don't
see any conflicts between judicious logging and systems that [rightly or wrongly]
are claimed to be more secure than passwords printed in clear on plastic cards.

no, I was refering to all the magic solutions that make things secure suddenly.
Like sms-tan instead of pin+tan, or funny devices reading flickering info on some banks online system,
or smart cards with biometrics on board, or $government-identified-super-secure-signing-cards or
stupid "de-mail" (email with a postage cost of half an euro) which they try to sell in germany, and
all this stuff.

switching from magstripe to EMV transactions ("chip+pin") seams to be a good idea though, as magstripe
is totaly unsecure. but the real foundation of the credit card business is the middle man that vouches against
both user and shop for any loss, and runs a fraud prevention programm to minimize risk and cost. this idea
is great, technical solutions are perfectly fine, if they keep this basic system. I complain that they try to do not.

EMV is of course totaly bloated and thus far too complex, and the whole idea of visa and mastercard keeping
paypass and paywave confidential, even partners under NDA only get to see their bits, that is real stupid and insecure.

I wonder how many years we need until people are willing to build an online only system. that won't work offline,
but could be soo much easier than the offline system. many banks have already moved e.g. their PINs from the
card to the online system, as unblocking a PIN in a card was often not working well, and having a central manged
IT is much easier. So banks are already willing to restrict at least certain functions like debit (cash from ATM) to
online only.

>
> The downside from my perspective is rather that visa and master card are shifting the liability to the end user.
> if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having
> a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require
> the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan
> as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty
> bank account.

3D Secure IMO combines the worst possible user-interface with questionable security.
However, the concept is actually brilliant but it will rather be Google and Apple
that will make it useful, not MasterCard and VISA.

well, no nfc in iphone5, thus no idea what plans Apple has, and I can't comment on Google.
 
> Lets be honest: you might have your mobile phone and wallet in your hand-bag or backpack or whatever, and if
> both are stolen the attacker has access to about everything and almost all ways to identify you and authorize
> transactions are in his hand. even the numbers you might need to know to prevent fraud are no longer with you -
> e.g. in germany I might remember the central hotline for reporting stolen cards (116 116) and I remember my bank
> account number. but if they require my visa card number, I wouldn't know that. also I wouldn't have mobile phone
> with me - it got stolen - and if I don't notice the issue I'm out of luck, as everyone (banks, telco, ...) shift the liability
> for every transaction until the theft gets reported to the customer.
>
> the mobile phones have authentication of the customer (gesture, pin, password or screen unlock), but those are not
> very good protections. so my expectation is they won't stop attackers.

I expect another kind of protection to be more useful and that is that the owner will be able
to set it "on hold" or possibly even in "wipe out" mode through a cloud service that the phone will
interrogate every now and then.  If the cloud service isn't available you must issue a "difficult"
password before gaining access to the device.  From what I can deduct from the rather scarce
Wallet documents, this is more or less already in place.  If the device is subject to a shrewd
attack I guess only the traditional credential revocation will help.  The cloud service may
aid you with that as well.

hmm. so if I designate my wife to be able to lockate and/or freeze and/or fry/lock/... my phone,
and she does vice-versa, than anyone getting either fone can fry the other phone as well?
ok, we can protect that with a password - but I need to remember it and still it needs to be safe.
not easy to solve.
 
I definitely believe that losing a mobile phone wallet will be less devastating than
losing a traditional one.  Naturally it has to be proved.  I believe there are a
billion or so "guinea pigs" out there who are wiling to try :-)

well, many apps in mobile phones are frontends for cloud services and keep a local cache only.
thus we should have a backup in the cloud. but we loose a token to all those parts of the cloud
as well. having a very limited number of SSO providers could be a good key to improving security.

Andreas
 

Anders



>
> Andreas
>
>
>
>     Anders
>
>
>     >
>     >> I must admit I don't know how many apps are managed and seperated. given
>     >> the restricted resources a smart card has,
>     > Think about how an MMU works: it keeps a table of "pages" assigned to an
>     > app, and maps 'em in app's address space. An app have no way to access a
>     > page outside its allowed address space. Nothing secret, here, and
>     > doesn't require great resources.
>     >
>     >> I only remember seeing code that would change master keys and put one
>     >> app into a card, thus never bothered how it works in detail or how to
>     >> manage resource, secure apps against each other etc. Also I wonder: does
>     >> the vendor claim to have the security thight enough to prevent a hostile
>     >> app from accessing data of another app? Or is it the usual "all is
>     >> secure", but we don't tell how it works,
>     >> how to use it, and make no real guaranties anyway?
>     > Another question: if the applet manager is secure, then why change
>     > master keys before giving a card to customers?
>     >
>     >> My new impression is I would only need to use a smart card key&cert with
>     >> one site only - my SSO provider. Thus a plugin for that communication
>     >> only would work well with me.
>     > As long as you can import/export your cert (better if keeping it
>     > protected by a password) then you can have quite good security using
>     > openid and an identity provider like startssl that authenticates you
>     > using that cert.
>     >
>     >> Not sure what to do about phone theft though - I really fear putting all
>     >> the access credentials into one basket (my phone), plus a lot of
>     >> personal information, so any thief would be able to
>     >> impersonate me and access my mail, documents, banks, and much more.
>     > For this I simply use keepass w/ its db synced over dropbox (and backed
>     > up offline in multiple places). Obviously a thief wouldn't have my
>     > master password, so the access to the db would be useless.
>     >
>     >> In summary: my old expectations how to secure communication and use
>     >> smart cards in them have gone many months ago, now I see the "world"
>     >> very differently. My adventures into smart card business also make me
>     >> wonder if trusting such an industry is a good thing.
>     > Always too many things under NDA or plainly unavailable, too often
>     > starting from comm specs...
>     >
>     > BYtE,
>     >  Diego.
>     > _______________________________________________
>     > opensc-devel mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://www.opensc-project.org/mailman/listinfo/opensc-devel
>     >
>
>     _______________________________________________
>     opensc-devel mailing list
>     [hidden email] <mailto:[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: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
In reply to this post by NdK-3
2012/9/24 NdK <[hidden email]>
Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto:

>> In my mind, the SE should take over display and touch controller by
>> hardware means, so absolutely no app can snoop user input or fake it.
>> Too bad seems nobody really *needs* that level of security...
> like "credsticks" from scifi novels decades ago? that owuld be a single use
> appliance, and I think easy to hack, similar how it is trivial to have a
> chip recording keystrokes placed inside a laptop etc. and I guess a multi
> app would be extreme complex and unlikely to be secure either.
Nope. Speaking of SE in smartphones here :)

well, that is lots of software in the smart phone that can be hacked.
not a secure entry device from my point of view.
 
You don't have much space inside a phone... Hopefully not enough to add
a logger chip. And a phone is really much more "tamper evident" than a
laptop...

hmm, not so sure about that. but even if that is true, the software is easier
to hack anyway, and requires only installing the wrong app "try this game",
thus has a much easier attack vector.
 
> hmm, a datasheat I found on smartmx for example does not mention a MMU.
> I guess it is onl a software implementation in the java interpreter, and
> that could be well faulty.
Software-emulated MMU, then. Since it's so simple, it could well be
worth the reduction in gates at the expense of a little longer run time
-- but you are already running java, not optimized asm...

well, in the end your programm is pretty simple I guess, and the complex
operations like crypto are in a library in the chip and not java bytecode.
 
> also how are things managed - how easy is it to setup things wrong?
That should be impossible, if the card only allows fixed-size apps and
went under throrought testing.

well, we saw so many insecurities in smart cards in the last few years - e.g. the hacks on mifare and legic, or the flaws found by ross anderson and his team on EMV cards - I doubt things are really secure, if they are very complex. 


>> Another question: if the applet manager is secure, then why change
>> master keys before giving a card to customers?
> cards go throug a pipeline of ~4 entities and everyone has his own secret
[...]
Uhm... Found. If the key was publicly known, a reseller could easily
remove an applet and replace it with another using the same app id and
the final user wouldn't be able to know.
If only the card manager would allow a per-app removal key...

well. who is the card manager. if I buy a phone without contract, is it the vendor?
if I buy a phone with a contract, is it the mobile network operator? will we have conflicts of interest?
we already have locked phones and preventing some functionality (voice over ip, tethering, ...),
and I guess phone companies want you to pay with your phone - as long as it ends up on the phone
bill and they get a share of each transaction?

thus who controls the SE has power, and it can't be you the end user, as the bank won't trust you to do a secure deployment.
 
>>> My new impression is I would only need to use a smart card key&cert with
>>> one site only - my SSO provider. Thus a plugin for that communication
>>> only would work well with me.
>> As long as you can import/export your cert (better if keeping it
>> protected by a password) then you can have quite good security using
>> openid and an identity provider like startssl that authenticates you
>> using that cert.
> certs don't need protection, only keys do. and being able to export a key
> is always a bad idea.
Unless you either can set up a multi-party RSA system or have another
way to recover a damaged key.

no one needs to recover keys. simply create a new one and create a new cert.
 
If exporting keys is always such a bad idea, then why root-CAs export
theirs? Simply to have a backup and obtain business continuity in case
of HSM failure.

HSM have all keys stored on the normal windows disk - but encrypted. the encryption is with AES or 3DES, and that is a master key that can be loaded into several HSM. often it is an XOR of N master key parts, and 4*N different persons have a copy of one part (two sites, two person each site). Thus worst case any copy of the key database plus parts 1..N can be used to setup a fresh HSM with the same master key and keep using those keys. standard practice for IBM HSMs at least I believe.

> it is much better to be able to get a new cert&key whenever you want on
> demand. e.g. enter your credentials
> (password, pin, tan, fingerprint, retina scan, secret handshake, whatever
> you think is secure) and then get/generate
> a new keypair and CSR and get the signed cert.
Unless you run a CA. :)

no. if you run a CA creating new certificates costs you nothing, so the best thing you can do for security is short lived certificates with fast automated secure refresh cycles. the reason why people have long lived certificates, is because it is such a hassle to create new ones and manage them, if you do it manually and not well trained and with little know-how.

> as for openid, I thought there was some discussion about it - v1 too
> complex, not much agreement on v2 or so?
Complex? Seems quite easy...

hmm, maybe I'm mixing openid, oauth and other stuff here? not an expert on these technologies.

>> Always too many things under NDA or plainly unavailable, too often
>> starting from comm specs...
comm=communication , sorry.

> common specs? I rather wonder: everyone invented something on his own, and
> when a standard came around, any change would break compatibility and more
> important require new certification rounds, thus would be expensive, thus
> everyyone preferred to not implement the standard. after all who wants to
> give users the choice to switch vendors? very bad idea, vendor lockin is
> king,
I'm still waiting for ACS to tell me something about how can I use my
cryptomate64 token. I could have its "reader" recognized, but ACOS5
protocol is still unsupported (I found a project, but it seems still in
its early stages...).

> other java cards than JCOP. And JCOP again is a prime example of a NDA
> thing, not a standard, right? or did it improve?
I have some JCOP cards, but just lately I found how to authenticate with
the card manager using Alexander Petric's hints for gpshell.
If I have't to sign NDAs to develop my own applets and load'em on card,
then for me it's "open enough".
But I still don't know if I have enough info (for example: how do I
handle RSA crypto? I hope there's a library with public API for that...).

so your JCOP cards have the public known dummy key on them?

thats nice for test cards, but some vendors sell them with real keys I think,
and then it is a large hassle to use them / negotiate re-keying first etc.

I think some people are paranoid to require a full tracking from chip production
to end user, with secure keys used during the whole chain, so each entity
has to negotiate keys with the previous and next entities and rekey the
SE when receiving and/or before handing it to the next entity.

I wonder why there is no counter for authenticating to the card, that never decreases or overflows? if you saw any card with the counter at 0, you would know that noone ever has changed anything, as that would require an authentication with fab keys first, and would increase the counter, and thus the fab key could be public and everyone could forward cards without re-keying.

but if people want to be flexible and buy from different source and via different routes, then they again like this chain with changing the card in each step, as they can hide how they got the SE and can make it look like every other SE they deliver. guess that is a very strong motivation to have a complex system.

Regards, Andreas
 

BYtE,
 Diego.
_______________________________________________
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: Technical Description - Android Embedded SE

NdK-3
In reply to this post by Andreas Jellinghaus-4
Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto:

> no, I was refering to all the magic solutions that make things secure
> suddenly.
there was a good comic strip I can't find just now...
Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way
we can recover it even with $1000000!
Grunt view: this laptop is locked... take this $5 wrench and beat off
the pass from the user.

Too bad it proves right... Here in Italy we've had many episodes of
people kidnapped to make their families let robbers enter well-protected
houses... :(

> Like sms-tan instead of pin+tan, or funny devices reading flickering
> info on some banks online system,
> or smart cards with biometrics on board, or
> $government-identified-super-secure-signing-cards or
> stupid "de-mail" (email with a postage cost of half an euro) which they
> try to sell in germany, and all this stuff.
Not to speak of italian "posta certificata" ("certified mail", with
provable delivery so that it can have legal value)... :)

> EMV is of course totaly bloated and thus far too complex, and the whole
> idea of visa and mastercard keeping
> paypass and paywave confidential, even partners under NDA only get to
> see their bits, that is real stupid and insecure.
Maybe because they know it's not secure?
EMV for sure: there's an unauthenticated bit that tells the card to
authenticate the transaction without asking for the PIN...

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

Re: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
2012/9/25 NdK <[hidden email]>
Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto:

> no, I was refering to all the magic solutions that make things secure
> suddenly.
there was a good comic strip I can't find just now...
Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way
we can recover it even with $1000000!
Grunt view: this laptop is locked... take this $5 wrench and beat off
the pass from the user.

Too bad it proves right... Here in Italy we've had many episodes of
people kidnapped to make their families let robbers enter well-protected
houses... :(

> Like sms-tan instead of pin+tan, or funny devices reading flickering
> info on some banks online system,
> or smart cards with biometrics on board, or
> $government-identified-super-secure-signing-cards or
> stupid "de-mail" (email with a postage cost of half an euro) which they
> try to sell in germany, and all this stuff.
Not to speak of italian "posta certificata" ("certified mail", with
provable delivery so that it can have legal value)... :)

> EMV is of course totaly bloated and thus far too complex, and the whole
> idea of visa and mastercard keeping
> paypass and paywave confidential, even partners under NDA only get to
> see their bits, that is real stupid and insecure.
Maybe because they know it's not secure?

No, I think it is well intended - try to be compatible with every old thing and have all the features everyone wants in there.
Except the result of such a process is not good.
 
EMV for sure: there's an unauthenticated bit that tells the card to
authenticate the transaction without asking for the PIN...

Thats ok, it is a valid feature. If people buy something for less than a dollar, and the transaction is authenticated with the
signature of a rsa key in the smart card, and we haven't reached the consecutive lower boundary amount yet, then simply
approving the transaction is perfectly fine - getting a PIN or doing an online transaction isn't worth doing for such a small
amount of money.

Most vending machines still use modems and dial up for every transaction and hang up again later.
Thats why card transactions are so slow. Once the standard is to have a permanent internet connection,
the cost of doing an online transaction is lower (less delay) and the profile could be changed to do everything online.
But since the card doesn't know where it is, it can only have a world wide setting, and people expect the card to
work in the remote places with the worst infrastructure. Maybe some day banks want to give people two credit cards
with different settings?

Andreas


BYtE,
 Diego.


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

Re: Technical Description - Android Embedded SE

NdK-3
Il 25/09/2012 07:58, Andreas Jellinghaus ha scritto:

>> EMV for sure: there's an unauthenticated bit that tells the card to
>> authenticate the transaction without asking for the PIN...
> Thats ok, it is a valid feature. If people buy something for less than a
> dollar, and the transaction is authenticated with the
> signature of a rsa key in the smart card, and we haven't reached the
> consecutive lower boundary amount yet, then simply
> approving the transaction is perfectly fine - getting a PIN or doing an
> online transaction isn't worth doing for such a small
> amount of money.
IIUC that bit is not authenticated, so a MITM attack can force both the
reader and the card think the other party doesn't support PIN auth,
making the card sign the transaction anyway, regardless the amount
involved. So IMVHO it's quite serious...

> Most vending machines still use modems and dial up for every transaction
> and hang up again later.
The stupid thing is that it seems they do the same for cellular-based
readers too... What a waste!

> Thats why card transactions are so slow. Once the standard is to have a
> permanent internet connection,
that won't change anything: many banks still use *mainframes* ! Some
still backup to (and transfer data with) tape *wheels* ! (when we
dismissed our IBM 9000, I think one of the tape units got sold to the
bank...). As long as "it works", they don't change it.

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

Re: Technical Description - Android Embedded SE

Peter Stuge-4
NdK wrote:
> IIUC that bit is not authenticated, so a MITM attack can force both the
> reader and the card think the other party doesn't support PIN auth,
> making the card sign the transaction anyway, regardless the amount
> involved. So IMVHO it's quite serious...

http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
http://youtu.be/gv3dxjvqk7Y


//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: Technical Description - Android Embedded SE

NdK-3
Il 25/09/2012 11:50, Peter Stuge ha scritto:

>> IIUC that bit is not authenticated, so a MITM attack can force both the
>> reader and the card think the other party doesn't support PIN auth,
>> making the card sign the transaction anyway, regardless the amount
>> involved. So IMVHO it's quite serious...
> http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
Tks. That's the (or one of) article I remembered but couldn't find...

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

Re: Technical Description - Android Embedded SE

Peter Stuge-4
NdK wrote:
> >> IIUC that bit is not authenticated, so a MITM attack can force both the
> >> reader and the card think the other party doesn't support PIN auth,
> >> making the card sign the transaction anyway, regardless the amount
> >> involved. So IMVHO it's quite serious...
> > http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
> Tks. That's the (or one of) article I remembered but couldn't find...

http://google.com/search?q=chip+and+pin+broken
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Technical Description - Android Embedded SE

Andreas Jellinghaus-4
2012/9/25 Peter Stuge <[hidden email]>
NdK wrote:
> >> IIUC that bit is not authenticated, so a MITM attack can force both the
> >> reader and the card think the other party doesn't support PIN auth,
> >> making the card sign the transaction anyway, regardless the amount
> >> involved. So IMVHO it's quite serious...
> > http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
> Tks. That's the (or one of) article I remembered but couldn't find...

http://google.com/search?q=chip+and+pin+broken

but the broken security demonstrated so far is related to misconfiguration,
and many other banks have correct card profiles and are not affected.

Regards, Andreas

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
12